snd-usb-midi, midi input, oss, oops!

snd-usb-midi, midi input, oss, oops!

[Fernando Pablo Lopez-Lezcano]

Some notes on my latest experiences with usb midi (using a
MidiSport 2x2). This is with 2.4.20-pre4 + lowlat + preempt +
capabilities + acpi on a Sony GRX laptop, using alsa cvs from
Friday (with a patch to undo the latest api changes).

There are a couple of issues I have found:
a) midi input does not work.
b) it is possible (by doing things I should not be doing :-)
   to generate a kernel oops.

So, starting from a cold reboot I start alsa with the internal
intel-8x0 soundcard and no additional configuration in
modules.conf for the usb midi interface (except for an
appropriate value in snd_cards_limit). The audio driver for
the internal card starts fine.

After the reboot is done I conect the MidiSport 2x2 usb MIDI
interface. Hotplug recognizes the card, fxload loads the
firmware, the interface disconnects and reconnects, hotplug
recognizes that and loads snd-usb-audio (both "audio" and
"usb-midi" have been blacklisted). And that's it. With no
extra configuration snd-usb-audio is not automatically loading
snd-usb-midi (bug?). So I go ahead and load snd-usb-midi by
hand.

cat /proc/asound/devices shows two cards, the second one with
two midi interfaces. Lsmod shows all devices loaded.

I start pd -mididev 2 (uses oss emulation for midi on card 2).
There is a test panel that lets me check audio and midi i/o. I
click on Midi OUT and I can see the midi out LED in the
MidiSport blinking. Sending midi from a keyboard makes the
Midi IN LED blink (so the midi bytes are getting to the
interface) but I see no activity in the program (which should
be showing the midi bytes being received). Checking
/proc/asound/card1/midi0 I can see that Output 0 has a
non-zero value of "Tx bytes", but Input O has received
nothing. Same with Muse which uses the native alsa interface.

So everything seems to indicate things are working but
nothing is received by the programs and alsa.

So I say, let's try the oss drivers.

I unload all the alsa modules related with the second card
(which is the MidiSport). After that I load both "audio" and
"usb-midi", they say they recognize the card and they set up
two interfaces, /dev/midi00 and /dev/midi01. Trying to use pd
gets the same results, output works, input does not.

Now I get curious and say, what if I load the alsa usb midi
modules? (I know I should not be doing this!) So I go ahead
and load snd-usb-audio and then snd-usb-midi, to my surprise
they load (I would imagine they would refuse to load because
the other driver is using the midi interface hardware):

Sep 16 15:42:06 nando kernel: snd-usb-midi: MIDIStreaming version 01.00
Sep 16 15:42:06 nando kernel: snd-usb-midi: detected 2 output jack(s) on endpoint 1
Sep 16 15:42:06 nando kernel: snd-usb-midi: detected 2 input jack(s) on endpoint 1
Sep 16 15:42:06 nando kernel: ALSA ../alsa-kernel/core/rawmidi.c:1425: unable  
to register OSS rawmidi device 1:0
Sep 16 15:42:06 nando kernel: snd-usb-midi: endpoint 1: created 2 output and 2  
input ports

Note that they cannot register the device (because usb-midi is
using it?) but the drivers stay loaded and seem to create the
endpoints. If I try to start pd things keep working (midi in
does not work, of course), but I get some errors (not
surprising):

Sep 16 15:42:48 nando kernel: usb-uhci.c: ENXIO c0008580, flags 0, urb  
deebaea0, burb defc3ce0
Sep 16 15:42:48 nando kernel: usbmidi: Cannot submit urb for MIDI-IN
Sep 16 15:43:31 nando kernel: usb-uhci.c: ENXIO c0008580, flags 0, urb  
deebaea0, burb defc3ce0
Sep 16 15:43:31 nando kernel: usbmidi: Cannot submit urb for MIDI-IN

So I unload all modules, both alsa and oss versions dealing
with the MidiSport. They unload cleanly.

The I load snd-usb-audio and snd-usb-midi _again_. They load.

If I start pd I get a kernel oops:

Sep 16 15:46:01 nando kernel: Unable to handle kernel paging request at  
virtual address 0c8d8e23
Sep 16 15:46:01 nando kernel: c011c078
Sep 16 15:46:01 nando kernel: *pde = 00000000
Sep 16 15:46:01 nando kernel: Oops: 0000
Sep 16 15:46:01 nando kernel: CPU:    0
Sep 16 15:46:01 nando kernel: EIP:    0010:[<c011c078>]    Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Sep 16 15:46:01 nando kernel: EFLAGS: 00010206
Sep 16 15:46:01 nando kernel: eax: de54a000   ebx: 00000001   ecx: 00000012    
edx: 0c8d8e0f
Sep 16 15:46:01 nando kernel: esi: da2ee1c0   edi: 00000002   ebp: 00000012    
esp: de54bee4
Sep 16 15:46:01 nando kernel: ds: 0018   es: 0018   ss: 0018
Sep 16 15:46:01 nando kernel: Process pd (pid: 2095, stackpage=de54b000)
Sep 16 15:46:01 nando kernel: Stack: dabb5f80 e096053c 0c8d8e0f 00000000  
00000002 de54a000 ddff5d20 da5042a0
Sep 16 15:46:01 nando kernel:        de54a000 c0116bdd de10b005 00000006  
ca839d9c de54a000 da2ee1c0 df486de0
Sep 16 15:46:01 nando kernel:        00000000 c013c283 df486de0 da2ee1c0  
da2ee1c0 df486de0 00000000 c160b360
Sep 16 15:46:01 nando kernel: Call Trace:    [<e096053c>] [<c0116bdd>]  
[<c013c283>] [<c013ae36>] [<c013ad3d>]
Sep 16 15:46:01 nando kernel:   [<c014538e>] [<c013b075>] [<c0108adb>]
Sep 16 15:46:01 nando kernel: Code: f6 42 14 02 74 04 31 db eb 07 ff 42 10 83  
4a 14 18 b8 00 e0

>>EIP; c011c078 <try_inc_mod_count+18/50>   <=====
Trace; e096053c <[soundcore]soundcore_open+6c/1e0>
Trace; c0116bdd <do_page_fault+19d/4df>
Trace; c013c283 <chrdev_open+53/90>
Trace; c013ae36 <dentry_open+e6/190>
Trace; c013ad3d <filp_open+4d/60>
Trace; c014538e <getname+5e/a0>
Trace; c013b075 <sys_open+35/a0>
Trace; c0108adb <system_call+33/38>
Code;  c011c078 <try_inc_mod_count+18/50>
00000000 <_EIP>:
Code;  c011c078 <try_inc_mod_count+18/50>   <=====
   0:   f6 42 14 02               testb  $0x2,0x14(%edx)   <=====
Code;  c011c07c <try_inc_mod_count+1c/50>
   4:   74 04                     je     a <_EIP+0xa> c011c082  
<try_inc_mod_count+22/50>
Code;  c011c07e <try_inc_mod_count+1e/50>
   6:   31 db                     xor    %ebx,%ebx
Code;  c011c080 <try_inc_mod_count+20/50>
   8:   eb 07                     jmp    11 <_EIP+0x11> c011c089  
<try_inc_mod_count+29/50>
Code;  c011c082 <try_inc_mod_count+22/50>
   a:   ff 42 10                  incl   0x10(%edx)
Code;  c011c085 <try_inc_mod_count+25/50>
   d:   83 4a 14 18               orl    $0x18,0x14(%edx)
Code;  c011c089 <try_inc_mod_count+29/50>
  11:   b8 00 e0 00 00            mov    $0xe000,%eax

Is there anything else I could test?

-- Fernando


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: snd-usb-midi, midi input, oss, oops!

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> After the reboot is done I conect the MidiSport 2x2 usb MIDI
> interface. Hotplug recognizes the card, fxload loads the
> firmware, the interface disconnects and reconnects, hotplug
> recognizes that and loads snd-usb-audio (both "audio" and
> "usb-midi" have been blacklisted). And that's it. With no
> extra configuration snd-usb-audio is not automatically loading
> snd-usb-midi (bug?). So I go ahead and load snd-usb-midi by
> hand.

snd-usb-midi should be loaded when you try to access the sequencer device.
"aconnect -o" or trying to play/record something usually does the job.

I think I have observed a similar bug when snd-usb-audio is already loaded
for another device without MIDI, but this isn't the case here.

> Sending midi from a keyboard makes the Midi IN LED blink (so the midi
> bytes are getting to the interface) but I see no activity in the
> program (which should be showing the midi bytes being received).
> Checking /proc/asound/card1/midi0 I can see that Output 0 has a
> non-zero value of "Tx bytes", but Input O has received nothing. Same
> with Muse which uses the native alsa interface.
>
> So everything seems to indicate things are working but
> nothing is received by the programs and alsa.

Please try the seq program in the alsa-lib/test directory to see whether
the sequencer device works.
"./seq decoder 72.0" will show incoming events.

> So I say, let's try the oss drivers.
>
> I unload all the alsa modules related with the second card
> (which is the MidiSport). After that I load both "audio" and
> "usb-midi", they say they recognize the card and they set up
> two interfaces, /dev/midi00 and /dev/midi01. Trying to use pd
> gets the same results, output works, input does not.

Neither driver working may indicate some problem with the 2x2 firmware.
Try using some other version.

> Now I get curious and say, what if I load the alsa usb midi
> modules? (I know I should not be doing this!) So I go ahead
> and load snd-usb-audio and then snd-usb-midi, to my surprise
> they load (I would imagine they would refuse to load because
> the other driver is using the midi interface hardware):

Please compare /proc/bus/usb/devices before and after. It really should
not be possible to replace a driver already connected to the device.

> Sep 16 15:42:06 nando kernel: snd-usb-midi: MIDIStreaming version 01.00
> Sep 16 15:42:06 nando kernel: snd-usb-midi: detected 2 output jack(s) on endpoint 1
> Sep 16 15:42:06 nando kernel: snd-usb-midi: detected 2 input jack(s) on endpoint 1
> Sep 16 15:42:06 nando kernel: ALSA ../alsa-kernel/core/rawmidi.c:1425: unable
> to register OSS rawmidi device 1:0
> Sep 16 15:42:06 nando kernel: snd-usb-midi: endpoint 1: created 2 output and 2
> input ports
>
> Note that they cannot register the device (because usb-midi is
> using it?) but the drivers stay loaded and seem to create the
> endpoints.

The OSS devices cannot be registered. The ALSA rawmidi and sequencer
devices should work.

> If I try to start pd things keep working (midi in
> does not work, of course), but I get some errors (not
> surprising):
>
> Sep 16 15:42:48 nando kernel: usb-uhci.c: ENXIO c0008580, flags 0, urb
> deebaea0, burb defc3ce0
> Sep 16 15:42:48 nando kernel: usbmidi: Cannot submit urb for MIDI-IN
> Sep 16 15:43:31 nando kernel: usb-uhci.c: ENXIO c0008580, flags 0, urb
> deebaea0, burb defc3ce0
> Sep 16 15:43:31 nando kernel: usbmidi: Cannot submit urb for MIDI-IN

usb-midi complains because snd-usb-midi has already submitted an urb.
This is to be expected in this situation.

> So I unload all modules, both alsa and oss versions dealing
> with the MidiSport. They unload cleanly.
>
> The I load snd-usb-audio and snd-usb-midi _again_. They load.
>
> If I start pd I get a kernel oops:

I think something got out of whack when two drivers tried to handle the
same device simultaneously.

> Is there anything else I could test?

Try to see what happens if you plug/unplug 50 times in 10 seconds.  ;-)


Regards,
Clemens



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: snd-usb-midi, midi input, oss, oops!

[Fernando Pablo Lopez-Lezcano]

> > firmware, the interface disconnects and reconnects, hotplug
> > recognizes that and loads snd-usb-audio (both "audio" and
> > "usb-midi" have been blacklisted). And that's it. With no
> > extra configuration snd-usb-audio is not automatically loading
> > snd-usb-midi (bug?). So I go ahead and load snd-usb-midi by
> > hand.
>
> snd-usb-midi should be loaded when you try to access the sequencer device.
> "aconnect -o" or trying to play/record something usually does the job.

"aconnect -o" does it, starting Muse (which uses alsa native
midi) does it but starting Pd (which uses the OSS emulation
midi raw devices) does not load the snd-usb-midi modules. Is
there a reason why the load is delayed? It makes more sense to
me to load them when the interface is plugged in, after all
the hardware is there and is usable and snd-usb-audio loads.
Or maybe I need to put something in /etc/modules.conf to
accomplish this?

> Neither driver working may indicate some problem with the 2x2 firmware.
> Try using some other version.

Thanks to an email from Michal Seta (off the list) the MIDI in
problem is solved. Apparently the Midisport 2x2 firmware does
not like any active MIDI inputs while the firmware is loading.
If you disconnect everything, plug in the interface to the usb
bus, load all the drivers and _then_ connect the input midi
cables everything is fine.

> Please compare /proc/bus/usb/devices before and after. It really should
> not be possible to replace a driver already connected to the device.

This is what it shows (diffs from previous state):

- first load all alsa drivers, including snd-usb-audio and snd-usb-midi
  [baseline]

- then unload all alsa drivers:

 S:  Product=Midisport 2x2
 S:  SerialNumber=Copyright (GPLv2) 2001 by Lars Doelle <lars.doelle@on-line.de>
 C:* #Ifs= 2 Cfg#= 1 Atr=00 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
-I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=snd-usb-audio
+I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=(none)
 E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
 E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

- just load the alsa audio drivers (alsasound startup script)
  [no changes]

- load the "audio" module
  [no changes]

- load the "usb-midi" module

 S:  SerialNumber=Copyright (GPLv2) 2001 by Lars Doelle <lars.doelle@on-line.de>
 C:* #Ifs= 2 Cfg#= 1 Atr=00 MxPwr=100mA
 I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
-I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=(none)
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=midi
 E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
 E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

- load snd-usb-audio, snd-usb-midi

 S:  Product=Midisport 2x2
 S:  SerialNumber=Copyright (GPLv2) 2001 by Lars Doelle <lars.doelle@on-line.de>
 C:* #Ifs= 2 Cfg#= 1 Atr=00 MxPwr=100mA
-I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
-I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=midi
+I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
+I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=snd-usb-audio
 E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
 E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms

So it appears things are being replaced when they should not be.

> > So I unload all modules, both alsa and oss versions dealing
> > with the MidiSport. They unload cleanly.
> >
> > The I load snd-usb-audio and snd-usb-midi _again_. They load.
> >
> > If I start pd I get a kernel oops:
>
> I think something got out of whack when two drivers tried to handle the
> same device simultaneously.

Definitely...
-- Fernando


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: snd-usb-midi, midi input, oss, oops!

[Michal Seta]

oups...  sorry.
I meant to send my tip to the list and not privately :)

glad it worked.

On Tue, 17 Sep 2002 12:47:48 -0700
Fernando Pablo Lopez-Lezcano <nando@ccrma.Stanford.EDU> wrote:

 
> Thanks to an email from Michal Seta (off the list) the MIDI in
> problem is solved. Apparently the Midisport 2x2 firmware does
> not like any active MIDI inputs while the firmware is loading.
> If you disconnect everything, plug in the interface to the usb
> bus, load all the drivers and _then_ connect the input midi
> cables everything is fine.
> 


-- 
./MiS

Michal Seta		http://creazone.eworldmusic.com/doc/mis
CreaZone		http://www.creazone.com
No One Receiving	http://www.noonereceiving.32k.org

upcoming release:
NOR - "The Release of the Wandering-Eyed Girl"
	http://www.grainofsound.com



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: snd-usb-midi, midi input, oss, oops!

[Patrick Shirkey]

Fernando Pablo Lopez-Lezcano wrote:
> 
> Thanks to an email from Michal Seta (off the list) the MIDI in
> problem is solved. Apparently the Midisport 2x2 firmware does
> not like any active MIDI inputs while the firmware is loading.
> If you disconnect everything, plug in the interface to the usb
> bus, load all the drivers and _then_ connect the input midi
> cables everything is fine.
> 

Added to the online docs.

-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================

"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: snd-usb-midi, midi input, oss, oops!

[Clemens Ladisch]

Fernando Pablo Lopez-Lezcano wrote:
> > snd-usb-midi should be loaded when you try to access the sequencer device.
> > "aconnect -o" or trying to play/record something usually does the job.
>
> "aconnect -o" does it, starting Muse (which uses alsa native
> midi) does it but starting Pd (which uses the OSS emulation
> midi raw devices) does not load the snd-usb-midi modules. Is
> there a reason why the load is delayed?

ALSA loads sequencer drivers lazily because most users only want to play
.wav and MP3^H^H^HOgg files and thus do not have to suffer the overhead of
the sequencer which is quite big. In most cases, the sequencer would have
been loaded because of the existence of the OPL3 FM synthesize which
nodody wants to use anyway.

> Or maybe I need to put something in /etc/modules.conf to
> accomplish this?

I think add-above/below could do what you want. Please have a look at the
manpage.

> > Please compare /proc/bus/usb/devices before and after. It really should
> > not be possible to replace a driver already connected to the device.
>
> This is what it shows (diffs from previous state):
>
> - first load all alsa drivers, including snd-usb-audio and snd-usb-midi
>   [baseline]
>
> - then unload all alsa drivers:
>
> -I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
> -I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=snd-usb-audio
> +I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
> +I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=(none)

Interface 0 is the AudioControl interface. Its purpose is to list all
AudioStreaming and MIDIStreaming interfaces of the device. In this case,
if0 has a pointer to MIDI if1 (see lsusb for the boring details), and
snd-usb-audio grabs both interfaces.

> - just load the alsa audio drivers (alsasound startup script)
>   [no changes]
>
> - load the "audio" module
>   [no changes]

audio looks at the control interface, doesn't find any AudioStreaming
interfaces, and therefore doesn't do anything.

> - load the "usb-midi" module
>
>  I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
> -I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=(none)
> +I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=midi

usb-midi does _not_ look at the control interface, it simply grabs all
MIDIStreaming interfaces. (The old snd-usb-midi driver from 0.9.0rc3 did
the same.)

> - load snd-usb-audio, snd-usb-midi
>
> -I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none)
> -I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=midi
> +I:  If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
> +I:  If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=snd-usb-audio
>
> So it appears things are being replaced when they should not be.

Yes.

Interface 0 doesn't have a driver, so the Linux kernel tries to load
snd-usb-audio for it. snd-usb-audio then looks at the list of streaming
interfaces (see above) and grabs interface 1 without checking if this
interface is used by another driver.

This is a bug in snd-usb-audio.


Regards,
Clemens



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

[PATCH] usbaudio.c steals interfaces from other drivers

[Clemens Ladisch]

The USB audio driver claims the streaming interfaces of the device even if
they have already been claimed by another driver. (See the thread
"snd-usb-midi, midi input, oss, oops!" for the gory details.)


Index: usbaudio.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/usb/usbaudio.c,v
retrieving revision 1.8
diff -u -r1.8 usbaudio.c
--- alsa-kernel/usb/usbaudio.c	13 Sep 2002 08:39:08 -0000	1.8
+++ alsa-kernel/usb/usbaudio.c	18 Sep 2002 12:35:47 -0000
@@ -1829,6 +1829,10 @@
 			continue;
 		}
 		iface = &config->interface[j];
+		if (usb_interface_claimed(iface)) {
+			snd_printdd(KERN_INFO "%d:%d:%d: skipping, already claimed\n", dev->devnum, ctrlif, j);
+			continue;
+		}
 		if (iface->altsetting[0].bInterfaceClass == USB_CLASS_AUDIO &&
 		    iface->altsetting[0].bInterfaceSubClass == USB_SUBCLASS_MIDI_STREAMING) {
 			if (snd_usb_create_midi_interface(chip, j, NULL) < 0) {



-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: [PATCH] usbaudio.c steals interfaces from other drivers

[Takashi Iwai]

At Wed, 18 Sep 2002 14:52:31 +0200 (METDST),
Clemens Ladisch wrote:
> 
> 
> The USB audio driver claims the streaming interfaces of the device even if
> they have already been claimed by another driver. (See the thread
> "snd-usb-midi, midi input, oss, oops!" for the gory details.)

nice spot.  applied to cvs.
thanks.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab