Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Jan 2012 19:29:56 +0100
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        freebsd-multimedia@freebsd.org
Cc:        Clemens Ladisch <clemens@ladisch.de>
Subject:   Re: M-Audio Oxygen 49: snd_uaudio cycles (loads, detaches, loads.... ad infinitum)
Message-ID:  <201201021929.56997.hselasky@c2i.net>
In-Reply-To: <201201021902.16849.hselasky@c2i.net>
References:  <1325263531.4997.4.camel@localhost> <4F01CC65.2070408@ladisch.de> <201201021902.16849.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 02 January 2012 19:02:16 Hans Petter Selasky wrote:
> 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.

Or make it optional via a sysctl. Though is clearly a violation of the USB 
specification, which mandates which requests are mandatory.

--HPS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201021929.56997.hselasky>