From owner-freebsd-multimedia@FreeBSD.ORG Mon Jan 2 18:32:24 2012 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF0A106566B for ; Mon, 2 Jan 2012 18:32:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id 07AC18FC0C for ; Mon, 2 Jan 2012 18:32:23 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 223866728; Mon, 02 Jan 2012 19:32:22 +0100 From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org Date: Mon, 2 Jan 2012 19:29:56 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <1325263531.4997.4.camel@localhost> <4F01CC65.2070408@ladisch.de> <201201021902.16849.hselasky@c2i.net> In-Reply-To: <201201021902.16849.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201021929.56997.hselasky@c2i.net> Cc: Clemens Ladisch Subject: Re: M-Audio Oxygen 49: snd_uaudio cycles (loads, detaches, loads.... ad infinitum) X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 18:32:24 -0000 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