Re: usbaudio: Support for USB audio v2.0 devices

[adelias <adelias@freemail.gr>]

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



_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel