[alsa-devel] Some information about UsbPre2 UAC2 support
Hi all,
The Sound Devices USBPre2 is an UAC2 device but recognized as a UAC1 device by Linux.
I have spend some time in order to found a solution. I have successfully setup my sound card as a UAC2 mode and I can play/record a 24/192khz without problem.
But my solution is very ugly and cannot be considered as a real solution. Perhaps alsa developers have an idea to integrated UAC2 support for the USBPRe2 in the standard stack....
There is two distinct problems: - The sound card recognizes Linux as a Windows OS and send a incorrect device descriptor. - The USB stack choose the bad configuration descriptor.
More details on first problem:
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. Extract of kernel source code: " NOTE: If USE_NEW_SCHEME() is true we will start by issuing a 64-byte GET_DESCRIPTOR request. This is what Windows does, so it may help with some non-standards-compliant devices."
So I have patched my kernel. In driver/usb/core/hub.c: #define GET_DESCRIPTOR_BUFSIZE 65 (instead 64)
This solve the first problem.
More details on the second problem:
Now, the USB device descriptor has two configuration descriptors :the first is a UAC1 and the second is a UAC2. My "lsusb -v -d 0926:" can be view at: http://pastebin.com/nFTN2E04
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.
That all, no other problem was detected. The Linux UAC2 stack seems to be OK with this sound card.
I joined (ugly) patches , built on linux 3.7.1.
If you have an idea about how have a standard support of UAC2 for the Sound Devices USBPRe2, I (and a lot of people) will be happy.
Thanks Olivier
PS: A thread exists on LAU : http://lists.linuxaudio.org/pipermail/linux-audio-user/2013-January/089199.h...
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.
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().
Regards, Clemens
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@ladisch.de À: shal@free.fr Cc: alsa-devel@alsa-project.org Envoyé: Samedi 26 Janvier 2013 21:29:10 Objet: Re: [alsa-devel] Some information about UsbPre2 UAC2 support
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.
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
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
----- Mail original -----
De: "Clemens Ladisch" clemens@ladisch.de À: alsa-devel@alsa-project.org Envoyé: Lundi 28 Janvier 2013 14:10:06 Objet: Re: [alsa-devel] Some information about UsbPre2 UAC2 support
shal@free.fr wrote:
shal@free.fr wrote:
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.
The scenario is : - I used a standard kernel (with 64 as get_descriptor buffer size) - I connect the sound card - the sound card recognize the OS as a Windows and sends a UAC1 only configuration and keep this state for all get_configuration - I reboot with modified kernel (with 65 as get_descriptor buffer size) - The sound card already provides a UAC1 only configuration - I plug/unplug the sound card (the UbsPre2 is usb powered) - Now the sound card provides a UAC1+UAC2 configuration
A usb_reset() can be helpful, perhaps?
Perhaps.
=> I will try this : - standard usb core driver (revert my ugly patch on huc.c and generic.c) - in the usb audio I will add a quirk for the vendor/product ID of my sound card - I performed a usb_reset() - I performed a get_descriptor using a usb_control() with 65 as buffer size - I choose the 2nd configuration descriptor
There is any chance that it works ?
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.)
I will ask more information to the Sound Devices developper.
Thank,
best regards, Olivier
shal@free.fr wrote:
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.
- I used a standard kernel (with 64 as get_descriptor buffer size)
...
- I reboot with modified kernel (with 65 as get_descriptor buffer size)
...
- Now the sound card provides a UAC1+UAC2 configuration
So the modified get_descriptor is stil necessary.
- I performed a usb_reset()
- I performed a get_descriptor using a usb_control() with 65 as buffer size
The USB core will already issue the get_descriptor request before the driver gets informed that the device is there, so this won't help.
Regards, Clemens
participants (2)
-
Clemens Ladisch -
shal＠free.fr