Date: Mon, 02 Jan 2012 16:25:25 +0100 From: Clemens Ladisch <clemens@ladisch.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: M-Audio Oxygen 49: snd_uaudio cycles (loads, detaches, loads.... ad infinitum) Message-ID: <4F01CC65.2070408@ladisch.de> In-Reply-To: <201112302241.55813.hselasky@c2i.net> References: <1325263531.4997.4.camel@localhost> <201112301859.32280.hselasky@c2i.net> <1325271329.3649.6.camel@localhost> <201112302241.55813.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote: > It looks like your device has a problem with the clear-stall of the BULK > endpoint used for MIDI. In other words it is not fully USB compliant. After devices whose descriptors were so broken that they couldn't ever run with newer Windows versions, after devices where (only!) the capture interface used big-endian samples, and after devices that corrupted their data buffer when receiving MIDI data with running status, I'm *extremely* surprised that there would be another M-Audio device with firmware bugs. > I'm not sure how we can avoid this. Plain MIDI does not have any error detection, so there is no error condition that could be reported with a stall. I've never seen a stalled MIDI endpoint, except for devices with broken hardware where the endpoint was stalled from the beginning and where a clear-stall wouldn't help. The Linux driver neither detects nor clears stalls, and works fine. It's obvious that clear-stall requests are not well tested in MIDI devices' firmwares, so I wouldn't be surprised if there were other devices that have the same bug, or even lock up. Is there a reason that umidi_probe/_open unconditionally issue clear- stalls, other than "just to be safe"? Regards, Clemens
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F01CC65.2070408>