shal@free.fr wrote:
shal@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.
That's strange; the get_descriptor request should be the same.
Can we have the vendor/product ID before the first get_configuration() ?
No.
A usb_reset() can be helpful, perhaps?
Perhaps.
Perhaps, we can do the same thing that the ASIO driver.
That's what I meant with the quirk. (The first configuration does have endpoints for high sample rates, but these aren't marked as being compatible with either UAC 1 or 2.)
Regards, Clemens