On Tue, Aug 25, 2009 at 2:01 AM, Clemens Ladisch<clemens@xxxxxxxxxx> wrote:
> Damien Zammit wrote:
>> S/PDIF mode works by setting the required flag
>> in usbaudio.c. I think the device can't do both simultaneously,
>> since different altsettings are required to set it.
>
> Does the Windows driver allow it?
In windows, you can map output ports 1-2 as analogue and 3-4 as spdif
but I don't know if they both work simultaneously, I am having trouble
using the windows software...
>> Remaining issues:
>> 1) Double check endianess of 24 bit capture.
>
> This should be apparent even in low-amplitude noise.
> Do you have a hex dump of recorded data?
First 2 samples of audio recorded with jackrec (hexdumped from wav file):
0D 00 00 EE FF FF
Seems to be little endian, which is consistent with the wav
standard... which implies the driver's capture endianess is correct.
(S24_3BE)
>> +mbox2_reboot:
>> + snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
>> + 0x85, 0xc0, 0x0001, 0x0000, &bootresponse, 0x0012, 1000);
>> +
>> + if (bootresponse == MBOX2_BOOT_LOADING) {
>> + snd_printdd("device not ready, resending boot sequence...\n");
>> + goto mbox2_reboot;
>> + }
>
> This could be made a loop. And it could run infinitely long; maybe you
> should add a timeout. (How long does it usually need?)
It takes about 3 seconds from the instant you modprobe the driver to
the lights coming on.
I don't know the correct way to code a timeout. I assume it involves
checking the clock at the start, and then checking it at regular
intervals to see if the time has elapsed.
I think a 6 second timeout would be appropriate.
>> + err = usb_get_descriptor(dev, USB_DT_DEVICE, 0,
>> + &dev->descriptor, sizeof(dev->descriptor));
>> + config = dev->actconfig;
>> + if (err < 0) snd_printdd("error usb_get_descriptor: %d\n", err);
>> + err = usb_reset_configuration(dev);
>
> Does this device change its descriptors without a reset?
>
>> + * 80 bb 00 = 24bit mode - S24_3BE
>> + * 44 ac 00 = 16bit mode?
>
> 0xbb80 = 48000
> 0xac44 = 44100
>
> Do the descriptors change if you change the sample rate? Or does using
> 44.1 kHz result in another altsetting?
The altsettings are the same for 44.1 and 48, and the windows driver
re-reads the descriptors quite often, and resets all altsettings on
ifaces 2-5 to 0 before setting the required altsettings, so I assume
they change. Does that mean we need to re-read the descriptors too
after every mode change?
I captured the setup packets & data required for setting the device
into 16/24 bit modes and 44.1/48kHz, but I'm not sure where to code
them in the driver so that ALSA can set the modes automatically, I
don't think it follows standard usb audio devices.
>> + snd_printdd("unknown bootresponse, ignoring device: %d\n",bootresponse);
>> + return -ENODEV;
>> + }
>> + snd_printdd("Invalid firmware size: %d\n",fwsize);
>> + return -ENODEV;
>
> snd_printdd is for debugging output, but a failure due to a new firmware
> revision should be indicated in any case.
Which "printf" function should i be using for this? I am a kernel newbie.
>> +#ifdef MBOX2_SPDIF_IO
>
> This should be done at runtime. This would need logic to prevent using
> analog/digital at the same time(?), and it might be necessary to
> hardcode interfaces and if numbers in find_format().
In windows, the I/O settings allow you to set SPDIF as a clock source
at runtime, but when I captured this over usbsnoop, there were no
setuppackets relating to this. (I know this because I worked out what
all the other setup packets do.)
Using SPDIF as a clock source, does that mean it uses spdif RCA jacks
as input/output? Or just using the digital input as a clock whilst
feeding the signals through the analogue jacks?
I don't have an external device with spdif to test...
>> + * We have to make sure that the USB core looks
>> + * again at interface 6
>
> Why?
Not sure, I just copied that code from another device... It seems to
work when I comment it out, so I'll get rid of it.
Regards,
Damien
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
