[PATCH] snd-usb-audio with multiple audio functions

[PATCH] snd-usb-audio with multiple audio functions

[Rolf Meeser]

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

Hello,

This patch fixes the currently broken support for multiple audio 
functions (AF) in snd-usb-audio.
The patch is against the stable 2.6.39.1 kernel.

It addresses three issues:
1. Controls of the second and any further AF are currently not 
accessibly (controls of the first AF are duplicated!)
2. Multiple AF's are currently incorrectly combined into one sound card 
index.
3. Module usage count of snd-usb-audio does not drop to zero after 
disconnecting a multiple AF device.

All three issues are fixed by assigning a new card index for each AF in 
a USB device.


Rationale:

- A USB audio function (AF) consists of a control interface and zero or 
more streaming interfaces. USB devices can have multiple AF, where the 
individual AF are completely independent of each other. In particular, 
it cannot be assumed that the controls of one AF can be manipulated 
through the control interface of another (the first) AF.

- Older kernels (up to 2.6.32? at least before the major rewrite of USB 
audio code) supported multiple AF's. However, they combined the streams 
into one sound card: For instance hw:1,0 for the stream interface of the 
first AF, and hw:1,1 for the stream interface of the second AF.
I believe this is incorrect, as different AF's must be treated as an 
independent entity. Each AF must get its own card index, for the example 
this would be hw:1,0 and hw:2,0. This is also the way THE OTHER OS 
implements it.

- Newer kernels have broken multiple AF support. In a dual AF setup 
these kernels detect the second AF, but they duplicate the controls of 
the first AF, and ignore the controls of the second one!

- The patch also fixes a problem with module usage: When you unplug a 
multiple AF device, the snd-usb-audio module usage count currently stays 
at 1, while you could expect it to go to zero.

This is the first time I'm sending a patch to this list. Please be 
patient with me if I did something in a wrong way :-)

Regards,
Rolf


[-- Attachment #2: patch-multiple-aic --]
[-- Type: text/plain, Size: 683 bytes --]

diff -ur linux-2.6.39.1.orig/sound/usb/card.c linux-2.6.39.1/sound/usb/card.c
--- linux-2.6.39.1.orig/sound/usb/card.c	2011-06-06 06:37:26.000000000 +0200
+++ linux-2.6.39.1/sound/usb/card.c	2011-06-06 07:06:06.000000000 +0200
@@ -461,7 +461,10 @@
 	chip = NULL;
 	mutex_lock(&register_mutex);
 	for (i = 0; i < SNDRV_CARDS; i++) {
-		if (usb_chip[i] && usb_chip[i]->dev == dev) {
+		if (usb_chip[i] &&
+			(usb_chip[i]->dev == dev) &&
+			(usb_chip[i]->ctrl_intf) &&
+			(usb_chip[i]->ctrl_intf->desc.bInterfaceNumber == ifnum)) {
 			if (usb_chip[i]->shutdown) {
 				snd_printk(KERN_ERR "USB device is in the shutdown state, cannot create a card instance\n");
 				goto __error;


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

Re: [PATCH] snd-usb-audio with multiple audio functions

[Daniel Mack]

Hi Rolf,

On Mon, Jun 6, 2011 at 8:49 AM, Rolf Meeser <rolfm_9dq@yahoo.de> wrote:
> Hello,
>
> This patch fixes the currently broken support for multiple audio functions
> (AF) in snd-usb-audio.
> The patch is against the stable 2.6.39.1 kernel.
>
> It addresses three issues:
> 1. Controls of the second and any further AF are currently not accessibly
> (controls of the first AF are duplicated!)
> 2. Multiple AF's are currently incorrectly combined into one sound card
> index.
> 3. Module usage count of snd-usb-audio does not drop to zero after
> disconnecting a multiple AF device.
>
> All three issues are fixed by assigning a new card index for each AF in a
> USB device.

I assume you have such a device? Which model is that?

> Rationale:
>
> - A USB audio function (AF) consists of a control interface and zero or more
> streaming interfaces. USB devices can have multiple AF, where the individual
> AF are completely independent of each other. In particular, it cannot be
> assumed that the controls of one AF can be manipulated through the control
> interface of another (the first) AF.
>
> - Older kernels (up to 2.6.32? at least before the major rewrite of USB
> audio code) supported multiple AF's. However, they combined the streams into
> one sound card: For instance hw:1,0 for the stream interface of the first
> AF, and hw:1,1 for the stream interface of the second AF.
> I believe this is incorrect, as different AF's must be treated as an
> independent entity. Each AF must get its own card index, for the example
> this would be hw:1,0 and hw:2,0. This is also the way THE OTHER OS
> implements it.
>
> - Newer kernels have broken multiple AF support. In a dual AF setup these
> kernels detect the second AF, but they duplicate the controls of the first
> AF, and ignore the controls of the second one!
>
> - The patch also fixes a problem with module usage: When you unplug a
> multiple AF device, the snd-usb-audio module usage count currently stays at
> 1, while you could expect it to go to zero.
>
> This is the first time I'm sending a patch to this list. Please be patient
> with me if I did something in a wrong way :-)

The patch itself looks reasonable to be, and I doubt it would break
any existing functions.

However, please have a look at Documentation/SubmittingPatches. In
particular, you need to have a comprehensive commit log (which can be
taken from your explanations in this email) and your "Signed-off-by:"
line above the actual patch. Would you care to resend?

Thanks a lot for sharing your work!

Daniel

Re: [PATCH] snd-usb-audio with multiple audio functions

[Takashi Iwai]

At Mon, 6 Jun 2011 10:45:49 +0200,
Daniel Mack wrote:
> 
> Hi Rolf,
> 
> On Mon, Jun 6, 2011 at 8:49 AM, Rolf Meeser <rolfm_9dq@yahoo.de> wrote:
> > Hello,
> >
> > This patch fixes the currently broken support for multiple audio functions
> > (AF) in snd-usb-audio.
> > The patch is against the stable 2.6.39.1 kernel.
> >
> > It addresses three issues:
> > 1. Controls of the second and any further AF are currently not accessibly
> > (controls of the first AF are duplicated!)
> > 2. Multiple AF's are currently incorrectly combined into one sound card
> > index.
> > 3. Module usage count of snd-usb-audio does not drop to zero after
> > disconnecting a multiple AF device.
> >
> > All three issues are fixed by assigning a new card index for each AF in a
> > USB device.
> 
> I assume you have such a device? Which model is that?
> 
> > Rationale:
> >
> > - A USB audio function (AF) consists of a control interface and zero or more
> > streaming interfaces. USB devices can have multiple AF, where the individual
> > AF are completely independent of each other. In particular, it cannot be
> > assumed that the controls of one AF can be manipulated through the control
> > interface of another (the first) AF.
> >
> > - Older kernels (up to 2.6.32? at least before the major rewrite of USB
> > audio code) supported multiple AF's. However, they combined the streams into
> > one sound card: For instance hw:1,0 for the stream interface of the first
> > AF, and hw:1,1 for the stream interface of the second AF.
> > I believe this is incorrect, as different AF's must be treated as an
> > independent entity. Each AF must get its own card index, for the example
> > this would be hw:1,0 and hw:2,0. This is also the way THE OTHER OS
> > implements it.
> >
> > - Newer kernels have broken multiple AF support. In a dual AF setup these
> > kernels detect the second AF, but they duplicate the controls of the first
> > AF, and ignore the controls of the second one!
> >
> > - The patch also fixes a problem with module usage: When you unplug a
> > multiple AF device, the snd-usb-audio module usage count currently stays at
> > 1, while you could expect it to go to zero.
> >
> > This is the first time I'm sending a patch to this list. Please be patient
> > with me if I did something in a wrong way :-)
> 
> The patch itself looks reasonable to be, and I doubt it would break
> any existing functions.

Yeah, I think so, too.

> However, please have a look at Documentation/SubmittingPatches. In
> particular, you need to have a comprehensive commit log (which can be
> taken from your explanations in this email) and your "Signed-off-by:"
> line above the actual patch. Would you care to resend?

FYI, about sign-off (and in general about the kernel patches), refer
to $LINUX/Documentation/SubmittingPatches document.


thanks,

Takashi

Re: [PATCH] snd-usb-audio with multiple audio functions

[Clemens Ladisch]

Rolf Meeser wrote:
> +		if (usb_chip[i] &&
> +			(usb_chip[i]->dev == dev) &&
> +			(usb_chip[i]->ctrl_intf) &&
> +			(usb_chip[i]->ctrl_intf->desc.bInterfaceNumber == ifnum)) {

Many audio devices with multiple vendor-specific interfaces do not have
a control interface.  This code would split them into multiple cards.


Regards,
Clemens

Re: [PATCH] snd-usb-audio with multiple audio functions

[Rolf Meeser]

Hi Takashi,

On 06/06/2011 11:08 AM, Takashi Iwai wrote:
>> The patch itself looks reasonable to be, and I doubt it would break
>> any existing functions.
> Yeah, I think so, too.
>
I have to disagree :-)
Even worse, I think it is almost nonsense.

Let me figure out another solution which will have to take Clemens' 
concerns into account.

>> However, please have a look at Documentation/SubmittingPatches. In
>> particular, you need to have a comprehensive commit log (which can be
>> taken from your explanations in this email) and your "Signed-off-by:"
>> line above the actual patch. Would you care to resend?
> FYI, about sign-off (and in general about the kernel patches), refer
> to $LINUX/Documentation/SubmittingPatches document.
>
I'll submit a clean patch next time!

Regards,
Rolf

Re: [PATCH] snd-usb-audio with multiple audio functions

[Clemens Ladisch]

Rolf Meeser wrote:
> On 06/06/2011 01:44 PM, Clemens Ladisch wrote:
> > Many audio devices with multiple vendor-specific interfaces do not have
> > a control interface.  This code would split them into multiple cards.
> 
> Breaking existing setups would indeed be bad.
> Are that cards with audio interfaces not following the Audio Class spec?

Yes.

> What would be the easiest way to identify them, so we could assign a new
> card index only in case of a compliant card?

Non-compliant devices don't have a control interface.

In theory, the USB core probes a device's interfaces in order, so the
control interface usually is probed first.  However, I'm not sure if
this is really true for all devices.  It's probably safest to check
explicitly if the device has any interface marked as audio control 1/2.


Regards,
Clemens