On 22/2/2010 6:28 μμ, Daniel Mack wrote:
Hi,
I've been working on support for USB devices compliant to audio class v2.0 and would like to share what I got.
First problem is that they literally changed every single descriptor type by adding or removing fields or changing their width, respectively. Even worse, some enum values were dropped and reassigned so their numerical value has a different meaning now.
My first step was to clean up most of the existing descriptor parsers by moving away from anonymous byte array access to real structs so we can see which fields we're actually dereferencing.
In a second step, I added definitions for the replacement descriptors and use them at appropriate places. The bInterfaceProtocol field must always be set correctly of course, otherwise we'll parse garbage.
Other things that have changed from v1.0 to v2.0 are:
The number of streaming interfaces is now reported by a standard interface association descriptor. The old approach using a proprietary descriptor extension is deprecated.
The number of channels per interface is now stored in the AS_GENERAL descriptor (used to be part of the FORMAT_TYPE descriptor).
The list of supported sample rates is no longer stored in a variable length appendix of the FORMAT_TYPE descriptor but is retrieved from the device using a class specific GET_RANGE command.
Supported sample formats are now reported as 32bit bitmap rather than as a fixed value. For now, this is worked around by choosing just one of them. Eventually, the code should propagate the full ability of the device.
A devices needs to have at least one CLOCK_SOURCE descriptor which denotes a clockID that is needed as argument to the class request command. If can have more than one though and the host driver is in charge to choose the right one. There are also new types for clock selectors and sample rate converters that a device might report. This is all unsupported at the moment. We only parse the first CLOCK_SOURCE and take this one.
Many descriptors (format_type, ...) have changed their layout. Handle this by casting the descriptors to the appropriate structs.
With the following patches applied, a v2.0 device is recognized and reported as ALSA device. I can even hear at least some kind of music, but the sample rate setting does not yet seem to be correct.
Also, the existing mixer code does not work at all for v2.0 devices. This will be quite some work to support that and I fear the whole thing must be reimplemented for v2.0 specifically. For now, I worked around that by not parsing them at all but bailing out very early.
However, I would like to make sure the changes I made so far won't cause any regression for v1.0 devices, and so it would be good to see them applied as a preliminary support. I'll continue working on this and send more updates along.
Let me know what you think.
Thanks, Daniel
Thanks to all involved for working on usb audio v2.
Last night I installed the 20100226 snapshot. I did a little testing with my XMOS board using toslink out into may DAC. I tried various files ranging 16bit/44110kHz-24bit/192000kHz. The 44110 files had quite a bit of static, the higher bitrate files were better. As you stated the sampling rate is not correct and be verified by looking at the flashing LEDs on the XMOS board. They should flash faster as sampling rate increase. In this case no change was observed.
Thanks, Nikos