[alsa-devel] Some information about UsbPre2 UAC2 support

[shal at free.fr]

Hi Clemens,

We already have been in contact for a bug resolution on my Edirol UA-1000.

My response bellow.


----- Mail original -----
> De: "Clemens Ladisch" <clemens at ladisch.de>
> À: shal at free.fr
> Cc: alsa-devel at alsa-project.org
> Envoyé: Samedi 26 Janvier 2013 21:29:10
> Objet: Re: [alsa-devel] Some information about UsbPre2 UAC2 support
> 
> shal at free.fr wrote:
> > For some compatibility raison, Sound device developer want only
> > send a UAC1 configuration when the Operating system is Windows.
> > The used method is based on the length of the  setup packet during
> > the device get_descriptor function.
> > If the length is 64, the OS is considered as Windows.
> > Linux have choosen also this value.
> 
> Because there are buggy devices that haven been tested only with
> Windows
> and will blow up if other values are chosen.
> 
> I guess somebody has to add a quirk for this device to the driver.

It is more complicated: Sound Devices don't want the same behavior between Mac OSX and Windows.
Some Windows does not support UAC2 by default (without ASIO driver).

The Sound Devices guy says :
"When the computer issues a STANDARD_REQUEST_GET_DESCRIPTOR we check the setupPacket.wLength field. If it is 64 then we limit the number of configurations to 1. Windows will only load the composite class driver if the configuration number is 1. (refer to
 http://minilien.fr/a0m7pj - note the line which says 'The device must have a single configuration'. )"

It's seems that the behavior of the sound card depends to the first get_configuration() and keep it until powered.
I discovers that when I performs a reboot in order to test my modified kernel : The sound card remains in UAC1.
I have to plug/unplug the sound card in order to have 2 configurations descriptor for this device.

I am afraid that it's a difficult problem to resolved.
I have not tested all possibilities.
Can we have the vendor/product ID before the first get_configuration() ?
A usb_reset() can be helpful, perhaps?
Perhaps, we can do the same thing that the ASIO driver.


> > Now, the USB device descriptor has two configuration descriptors
> > :the first is a UAC1 and the second is a UAC2.
> >
> > As UAC1 is a valid configuration descriptor, the usb stack choose
> > this configuration.
> >
> > I have patched the usb_choose_configuration() function in file
> > driver/usb/core/generic.c for overwrite the value with the good
> > one.
> 
> This can be changed later in the driver with
> usb_driver_set_configuration().

Thank, I will try to write a clean patch as a quirk for this problem.

Regards,
Olivier