Date: Mon, 2 Jan 2012 19:02:16 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Clemens Ladisch <clemens@ladisch.de> Cc: freebsd-multimedia@freebsd.org Subject: Re: M-Audio Oxygen 49: snd_uaudio cycles (loads, detaches, loads.... ad infinitum) Message-ID: <201201021902.16849.hselasky@c2i.net> In-Reply-To: <4F01CC65.2070408@ladisch.de> References: <1325263531.4997.4.camel@localhost> <201112302241.55813.hselasky@c2i.net> <4F01CC65.2070408@ladisch.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 January 2012 16:25:25 Clemens Ladisch wrote: > 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"? The reason is just to clear any buffered data from previous transfers. We could probably skip this. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201021902.16849.hselasky>