Some information about UsbPre2 UAC2 support

Some information about UsbPre2 UAC2 support

[shal]

[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]

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.html

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: choose_configuration.patch --]
[-- Type: text/x-patch; name=choose_configuration.patch, Size: 537 bytes --]

--- linux-3.7.1/drivers/usb/core/generic.c	2012-12-17 20:14:54.000000000 +0100
+++ linux-3.7.1-shal/drivers/usb/core/generic.c	2013-01-26 18:09:14.363789986 +0100
@@ -150,6 +150,14 @@
 			"no configuration chosen from %d choice%s\n",
 			num_configs, plural(num_configs));
 	}
+	
+	if(udev->product != NULL)
+	 if(strlen(udev->product) >= 7)
+	  if(strncmp(udev->product,"USBPre2",7) == 0)
+		{
+			i++;
+			printk("Overwrite the choosen configuration to the follower :%d in order to support USBPre2 in UAC2\n",i);
+		}
 	return i;
 }
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: get_descriptor_bufsize.patch --]
[-- Type: text/x-patch; name=get_descriptor_bufsize.patch, Size: 434 bytes --]

--- linux-3.7.1/drivers/usb/core/hub.c	2012-12-17 20:14:54.000000000 +0100
+++ linux-3.7.1-shal/drivers/usb/core/hub.c	2013-01-26 18:08:22.552319480 +0100
@@ -3865,7 +3865,9 @@
 			struct usb_device_descriptor *buf;
 			int r = 0;
 
-#define GET_DESCRIPTOR_BUFSIZE	64
+//#define GET_DESCRIPTOR_BUFSIZE	64
+#define GET_DESCRIPTOR_BUFSIZE	65
+
 			buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO);
 			if (!buf) {
 				retval = -ENOMEM;

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: Some information about UsbPre2 UAC2 support

[Clemens Ladisch]

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

Re: Some information about UsbPre2 UAC2 support

[shal]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Some information about UsbPre2 UAC2 support

[Clemens Ladisch]

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

Re: Some information about UsbPre2 UAC2 support

[shal]

----- 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Some information about UsbPre2 UAC2 support

[Clemens Ladisch]

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