[alsa-devel] [PATCH 1/1] sound: usb-audio: support for Digidesign Mbox 2

Damien Zammit damien.zammit at gmail.com
Thu Aug 27 03:22:33 CEST 2009


On Tue, Aug 25, 2009 at 2:01 AM, Clemens Ladisch<clemens at ladisch.de> 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


More information about the Alsa-devel mailing list