M-Audio USB Quattro on 2.6.x

M-Audio USB Quattro on 2.6.x

[Sampo Savolainen]

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

Hello to both alsa-devel and linux-usb-devel,


As most of you who have seen the words "USB Quattro" and "2.6.x"
together know, these two don't mix well. I have been investigating this
issue for some time and here are a few conclusions:

 1. The Quattro's alternate settings (usb jargon) are wrong
    (not-in-spec), and kernel doesn't accept the device.
 2. M-Audio says that it has done nothing wrong and haven't issued
    firmware updates (which as far as I know, are not possible on
    the Quattro).
 3. USB-IF says that M-Audio are violating the specs, but they can't
    force them to correct these issues because the USB logo is not
    on the device (that requires licensing and compliance). Only the
    USB trident is on the box, and that doesn't apply.

USB-IF has said, that these kinds of misinterpretations of the spec are
normal, and most operating systems just work around them. This isn't
'the right way to do it', but at the moment it seems like the only way
to do it.

To remedy this situation I've been working on a patch to the usb core.
The patch is attached as a part of this mail. This patch is not finished
yet, it has an unloading issue! This is why I'm writing this mail to you
all.

This patch is for Linux 2.6.2, it patches drivers/usb/core/config.c
(cd linux-2.6.2; patch -p0 < ../whereisit?/usbconfig.patch)

The changes I've made are commented, but here's a short list:
(All changes are for the code that configures new USB devices)

- Instead of counting how many alternate settings each interface has, it
  sets the number of alternate settings to (largest found altsetting)+1.
- Thus all the alternate settings are saved at the corresponding cell of
  the interface->altsetting pointer. If an altsetting is missing, that
  cell will be left blank.
- After parsing each alternate setting, instead of reporting an error
  for unset altsettings, the code truncates the list. If the list
  was modified, a new pointer will be allocated and the old one will be
  freed.

With this patch, I've got my Quattro working.
The problem is this:
If snd_usb_audio finds the soundcard, the card works well, until it is
removed. The kernel will see the device disconnect, but after that you
cannot reconnect the device. Nothing comes in the logs from connecting
the cable. Also, removing the snd_usb_audio module will result in the
command hanging. Not even 'kill -KILL [pid]' as root will kill the
process.

If snd_usb_audio isn't loaded, the soundcard can be reconnected again
and again and again without any problems-

I can think of a few things that could go wrong
 - I've missed something that the USB drivers do with the descriptor
   afterwards, especially when the descirptor is given to the
   approriate registered driver. Some checks aren't done because all
   devices should have all alternate settings?... 
 - The snd_usb_audio driver does something wild when all alternative
   settings aren't set.
 - Not much testing has been done on snd_usb_audio on 2.[56].x because
   the Quattro hasn't worked at all.

Could someone with more experience in this area help me?


 Thank you,
   Sampo Savolainen


[-- Attachment #2: usbconfig.patch --]
[-- Type: text/x-patch, Size: 2719 bytes --]

--- ../ko/linux-2.6.2/drivers/usb/core/config.c	2004-02-04 05:43:06.000000000 +0200
+++ drivers/usb/core/config.c	2004-02-16 16:36:15.000000000 +0200
@@ -202,8 +202,9 @@
 int usb_parse_configuration(struct usb_host_config *config, char *buffer, int size)
 {
 	int nintf, nintf_orig;
-	int i, j;
+	int i, j, k; // added k, v2 18:52 2004-02-15
 	struct usb_interface *interface;
+	struct usb_host_interface *altsetbuf; // added, v2 12:17 2004-02-16
 	char *buffer2;
 	int size2;
 	struct usb_descriptor_header *header;
@@ -265,8 +266,20 @@
 				    i, nintf_orig);
 				return -EINVAL;
 			}
-			if (i < nintf)
-				++config->interface[i]->num_altsetting;
+			if (i < nintf) {
+				// modified, v2 18:19 2004-02-15
+				// instead of increasing the number of altsettings by one per alternate setting
+				// found, set the number to largest found altsetting plus one
+				// Example:
+				// d->bAlternateSetting = 0,1,3
+				// config->interface[i]->num_altsetting = 4
+
+				if (config->interface[i]->num_altsetting < d->bAlternateSetting+1)
+					config->interface[i]->num_altsetting = d->bAlternateSetting+1;
+				
+				// old code
+				//++config->interface[i]->num_altsetting;
+			}
 
 		} else if ((header->bDescriptorType == USB_DT_DEVICE ||
 		    header->bDescriptorType == USB_DT_CONFIG) && j) {
@@ -340,12 +353,40 @@
 	/* Check for missing altsettings */
 	for (i = 0; i < nintf; ++i) {
 		interface = config->interface[i];
+		size2 = interface->num_altsetting;
 		for (j = 0; j < interface->num_altsetting; ++j) {
 			if (!interface->altsetting[j].desc.bLength) {
+				// new code, v2 18:54 2004-02-15
+				// move interfaces at j+1..interface->num_altsetting one left and 
+				// decrease interface->num_altsetting by one
+				
+				warn("missing altsetting %d for interface %d, moving alternate settings left", j, i);
+				--interface->num_altsetting;
+				for (k=j; k<interface->num_altsetting; ++k)
+					interface->altsetting[k] = interface->altsetting[k+1];
+				--j;
+				
+				/* old code
 				warn("missing altsetting %d for interface %d", j, i);
 				return -EINVAL;
+				*/
 			}
 		}
+		if (size2 != interface->num_altsetting) {
+			// new code, v2 12:34 2004-02-16
+			// allocate new interface->altsetting with the truncated size and free
+			// the old buffer
+			len = sizeof(*interface->altsetting) * interface->num_altsetting;
+			
+			altsetbuf = interface->altsetting;
+			interface->altsetting = kmalloc(len, GFP_KERNEL);
+			memcpy(interface->altsetting,altsetbuf,len);
+
+			kfree(altsetbuf);
+			
+			warn("truncated alternate settings on interface %d from %d to %d",
+			     i,size2,interface->num_altsetting);
+		}
 	}
 
 	return size;
@@ -484,3 +525,4 @@
 	return result;
 }
 
+

Re: M-Audio USB Quattro on 2.6.x

[Frank Barknecht]

Hallo,
Sampo Savolainen hat gesagt: // Sampo Savolainen wrote:

> As most of you who have seen the words "USB Quattro" and "2.6.x"
> together know, these two don't mix well. I have been investigating this
> issue for some time and here are a few conclusions:
> 
... 
>  3. USB-IF says that M-Audio are violating the specs, but they can't
>     force them to correct these issues because the USB logo is not
>     on the device (that requires licensing and compliance). Only the
>     USB trident is on the box, and that doesn't apply.

You did ask USB-IF? Is there something like an "official" statement by
the forum somewhere? 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: M-Audio USB Quattro on 2.6.x

[Alan Stern]

On Mon, 16 Feb 2004, Sampo Savolainen wrote:

> Hello to both alsa-devel and linux-usb-devel,
> 
> 
> As most of you who have seen the words "USB Quattro" and "2.6.x"
> together know, these two don't mix well. I have been investigating this
> issue for some time and here are a few conclusions:
> 
>  1. The Quattro's alternate settings (usb jargon) are wrong
>     (not-in-spec), and kernel doesn't accept the device.
>  2. M-Audio says that it has done nothing wrong and haven't issued
>     firmware updates (which as far as I know, are not possible on
>     the Quattro).
>  3. USB-IF says that M-Audio are violating the specs, but they can't
>     force them to correct these issues because the USB logo is not
>     on the device (that requires licensing and compliance). Only the
>     USB trident is on the box, and that doesn't apply.
> 
> USB-IF has said, that these kinds of misinterpretations of the spec are
> normal, and most operating systems just work around them. This isn't
> 'the right way to do it', but at the moment it seems like the only way
> to do it.

You didn't say exactly what the Quattro is doing wrong.  I can guess that 
it doesn't number its altsettings sequentially starting from 0.  Is that 
right?

> To remedy this situation I've been working on a patch to the usb core.
> The patch is attached as a part of this mail. This patch is not finished
> yet, it has an unloading issue! This is why I'm writing this mail to you
> all.
> 
> This patch is for Linux 2.6.2, it patches drivers/usb/core/config.c
> (cd linux-2.6.2; patch -p0 < ../whereisit?/usbconfig.patch)
> 
> The changes I've made are commented, but here's a short list:
> (All changes are for the code that configures new USB devices)
> 
> - Instead of counting how many alternate settings each interface has, it
>   sets the number of alternate settings to (largest found altsetting)+1.
> - Thus all the alternate settings are saved at the corresponding cell of
>   the interface->altsetting pointer. If an altsetting is missing, that
>   cell will be left blank.
> - After parsing each alternate setting, instead of reporting an error
>   for unset altsettings, the code truncates the list. If the list
>   was modified, a new pointer will be allocated and the old one will be
>   freed.
> 
> With this patch, I've got my Quattro working.
> The problem is this:
> If snd_usb_audio finds the soundcard, the card works well, until it is
> removed. The kernel will see the device disconnect, but after that you
> cannot reconnect the device. Nothing comes in the logs from connecting
> the cable. Also, removing the snd_usb_audio module will result in the
> command hanging. Not even 'kill -KILL [pid]' as root will kill the
> process.
> 
> If snd_usb_audio isn't loaded, the soundcard can be reconnected again
> and again and again without any problems-
> 
> I can think of a few things that could go wrong
>  - I've missed something that the USB drivers do with the descriptor
>    afterwards, especially when the descirptor is given to the
>    approriate registered driver. Some checks aren't done because all
>    devices should have all alternate settings?... 

Yes, although in your case the only driver in question is snd_usb_audio.  
You might also have trouble trying to read /proc/bus/usb/devices.

>  - The snd_usb_audio driver does something wild when all alternative
>    settings aren't set.
>  - Not much testing has been done on snd_usb_audio on 2.[56].x because
>    the Quattro hasn't worked at all.
> 
> Could someone with more experience in this area help me?
> 
> 
>  Thank you,
>    Sampo Savolainen

As you've seen, the problem isn't so easy to solve.  Yes, the USB core can
be patched as you've done to accept devices that number their altsettings
incorrectly.  Unforunately, there are many device drivers that assume the
numbering is done right.  They try to access the data for altsetting n by
looking at position n in the array of altsettings -- with your alterations
that won't work.  Unless you can change those drivers as well as the core,
you will run into exactly the sort of thing you're seeing here.

There hasn't been much call for making the kernel allow out-of-spec
altsetting numbers; the vast majority of devices seem to get this right.
Maybe if enough people really want it, it will be added in.

Alan Stern




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: M-Audio USB Quattro on 2.6.x

[Sampo Savolainen]

Hello,

I contacted the tech support at usb.org. I got in touch with a man
called Mark Paxson from USB-IF Compliance. I described the problem we
are having with the Quattro. I quote from his answer:

> Does the device you identify carry the USB-IF logo as displayed at the
> top of the USB.ORG website http://www.usb.org/home?  If so, they are
> in violation and the USB-IF can contact them.

To which I sent pictures of the Quattro, and the answer was:

> The icon they are using is called the USB Trident and is part of the
> USB specification for identifying a USB port. You are correct in that
> they are not in violation of a license agreement for using that icon. 
> So there's not much the USB-IF can do in regard to their
> non-compliance.

In short, they do not have the authority to force M-Audio to change the
behaviour of the device. So, if M-Audio doesn't supply firmware updates,
we have to select one of these:

 a) Stick with 2.4.x
 b) Try to reverse engineer the firmware. Which is almost impossible,
    because I do not know of any tools to get firmware out of the device
    or if the Quattro even supports firmware updates.
 c) Get 2.6.x to accept the device despite the strange settings.


 Sampo Savolainen


On Mon, 2004-02-16 at 19:29, Frank Barknecht wrote:
> Hallo,
> Sampo Savolainen hat gesagt: // Sampo Savolainen wrote:
> 
> > As most of you who have seen the words "USB Quattro" and "2.6.x"
> > together know, these two don't mix well. I have been investigating this
> > issue for some time and here are a few conclusions:
> > 
> ... 
> >  3. USB-IF says that M-Audio are violating the specs, but they can't
> >     force them to correct these issues because the USB logo is not
> >     on the device (that requires licensing and compliance). Only the
> >     USB trident is on the box, and that doesn't apply.
> 
> You did ask USB-IF? Is there something like an "official" statement by
> the forum somewhere? 
> 
> ciao



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: [linux-usb-devel] M-Audio USB Quattro on 2.6.x

[Sampo Savolainen]

On Mon, 2004-02-16 at 19:50, Alan Stern wrote:
> You didn't say exactly what the Quattro is doing wrong.  I can guess that 
> it doesn't number its altsettings sequentially starting from 0.  Is that 
> right?

Oops. I forgot that.

Yes, it's an alternate setting numbering issue.

> Yes, although in your case the only driver in question is snd_usb_audio.  
> You might also have trouble trying to read /proc/bus/usb/devices.

lsusb works fine, and I can read /proc/bus/usb/devices very well.
Actually, lsbus and /proc/bus/usb still shows the Quattro, even after
disconnecting it.

Also something I forgot: The kernel won't find ANY usb device after
disconnecting, not even on another controller than the one that the
Quattro was attached to.

> As you've seen, the problem isn't so easy to solve.  Yes, the USB core can
> be patched as you've done to accept devices that number their altsettings
> incorrectly.  Unforunately, there are many device drivers that assume the
> numbering is done right.  They try to access the data for altsetting n by
> looking at position n in the array of altsettings -- with your alterations
> that won't work.  Unless you can change those drivers as well as the core,
> you will run into exactly the sort of thing you're seeing here.
> 
> There hasn't been much call for making the kernel allow out-of-spec
> altsetting numbers; the vast majority of devices seem to get this right.
> Maybe if enough people really want it, it will be added in.

I know of at least two "USB" soundcards that have this problem. At least
M-Audios Quattro and Audiophile. Probably both of them would work if
this patch would be applied to the kernel with a correction to the
snd_usb_audio driver. For us audiogeeks this would be wonderful news.

On the other hand. I do not know enough about linux-usb development. So
I don't know what kind of issues this patch could create.

I haven't asked around, so I do not know how many people need this, but
I have been in touch with at least three others who use this hardware on
Linux. I think I'm speaking for everyone (of us four...) when I say we
really, really, want this feature!

(Before I get really excited, this patch has to be tested more
strenuously before adding it in)

Meanwhile, I'll try to find someone on the alsa side to help me find the
problem in snd_usb_audio. Just to make sure, your opinion is that the
patch is fine and the problem is on the driver side?


 Thanks for the help,
   Sampo Savolainen




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: M-Audio USB Quattro on 2.6.x

[Alan Stern]

On Mon, 16 Feb 2004, Sampo Savolainen wrote:

> lsusb works fine, and I can read /proc/bus/usb/devices very well.
> Actually, lsbus and /proc/bus/usb still shows the Quattro, even after
> disconnecting it.
> 
> Also something I forgot: The kernel won't find ANY usb device after
> disconnecting, not even on another controller than the one that the
> Quattro was attached to.

Both of those are signs that the sound driver is hung in its disconnect 
routine.  You can verify this by doing a stack trace (Alt-SysRq-T) and 
looking where the khubd thread is executing.

> > There hasn't been much call for making the kernel allow out-of-spec
> > altsetting numbers; the vast majority of devices seem to get this right.
> > Maybe if enough people really want it, it will be added in.
> 
> I know of at least two "USB" soundcards that have this problem. At least
> M-Audios Quattro and Audiophile. Probably both of them would work if
> this patch would be applied to the kernel with a correction to the
> snd_usb_audio driver. For us audiogeeks this would be wonderful news.
> 
> On the other hand. I do not know enough about linux-usb development. So
> I don't know what kind of issues this patch could create.
> 
> I haven't asked around, so I do not know how many people need this, but
> I have been in touch with at least three others who use this hardware on
> Linux. I think I'm speaking for everyone (of us four...) when I say we
> really, really, want this feature!

The person to convince is Greg KH <greg@kroah.com>, the overall maintainer 
for the USB subsystem.  He monitors the USB-development list (although I 
haven't seen much posted by him in a while; he must be busy with other 
things).

> (Before I get really excited, this patch has to be tested more
> strenuously before adding it in)
> 
> Meanwhile, I'll try to find someone on the alsa side to help me find the
> problem in snd_usb_audio. Just to make sure, your opinion is that the
> patch is fine and the problem is on the driver side?

I haven't studied it in detail.  The general idea is fine -- perhaps the
implementation could be improved a bit.  The problem you are facing now is
almost certainly in the sound driver.  Maybe just in its disconnect
routine, maybe more widespread.

But the real obstacle to adopting your patch is that it affects _every_ 
USB device driver, since any USB device might have this issue of 
mis-numbered altsettings.  You would have to go through every single 
driver and make sure that it would work okay with the patch.  I expect 
that several of them would need to be changed.

Alan Stern



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: M-Audio USB Quattro on 2.6.x

[Frank Barknecht]

Hallo,
Alan Stern hat gesagt: // Alan Stern wrote:

> You didn't say exactly what the Quattro is doing wrong.  I can guess that 
> it doesn't number its altsettings sequentially starting from 0.  Is that 
> right?

Maybe you remember that post by my last week or so on linux-usb-devel
asking for an explanation of "what does invalid alternate setting
mean" which you kindly answered with an explanation. That's the one, I
also posted a "cat /proc/bus/usb/devices  | grep Alt" for the Quattro. 

I did test a whole bunch of USB audio devices that week, 21 devices to
be exact. Tests were done on 2.4.22 and 2.6.2-rc3. I didn't have the
M-Audio Audiophile USB, but the Quattro which showed described
behaviour. 

*All* the 20 other devices got the alt numbering right, though. 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: M-Audio USB Quattro on 2.6.x

[Greg KH]

On Mon, Feb 16, 2004 at 02:58:32PM -0500, Alan Stern wrote:
> > I haven't asked around, so I do not know how many people need this, but
> > I have been in touch with at least three others who use this hardware on
> > Linux. I think I'm speaking for everyone (of us four...) when I say we
> > really, really, want this feature!
> 
> The person to convince is Greg KH <greg@kroah.com>, the overall maintainer 
> for the USB subsystem.  He monitors the USB-development list (although I 
> haven't seen much posted by him in a while; he must be busy with other 
> things).

Hey, I'm still here :)

Been working a lot on udev lately...  No new usb development from me
recently.

greg k-h


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel