From owner-freebsd-multimedia@FreeBSD.ORG Fri Jan 27 22:47:16 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1547516A43A for ; Fri, 27 Jan 2006 22:47:16 +0000 (GMT) (envelope-from nblists@anastigmatix.net) Received: from world.securenet-server.net (world.securenet-server.net [63.247.91.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B0D043D49 for ; Fri, 27 Jan 2006 22:47:14 +0000 (GMT) (envelope-from nblists@anastigmatix.net) Received: from pool-71-98-100-136.ipslin.dsl-w.verizon.net ([71.98.100.136]) by world.securenet-server.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1F2cIp-0002um-Uq; Fri, 27 Jan 2006 17:42:48 -0500 Message-ID: <43DAA4E3.6030808@anastigmatix.net> Date: Fri, 27 Jan 2006 17:55:31 -0500 From: Chapman Flack User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandre Ratchov References: <43DA4BE7.6070701@anastigmatix.net> <20060127215301.GA25336@moule.localdomain> In-Reply-To: <20060127215301.GA25336@moule.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - world.securenet-server.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-multimedia@freebsd.org, tech@openbsd.org Subject: Re: Return of the MIDI 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: Fri, 27 Jan 2006 22:47:16 -0000 Alexandre Ratchov wrote: > i don't understand completely the new cable number quirks; you say that the > midiman 2x4 have 4 jacks, that can be written (arbitrary?) on 2 endpoints. > Isn't this specified in any descriptors? For devices that conform to the actual "USB Device Class Specification for MIDI Devices," there are indeed endpoint and jack descriptors that can be retrieved from the device that completely specify how it should be used. The Midisport 2x4 is an example of a device that is marketed as a MIDI adapter for USB, but it does not conform to the USB MIDI spec, does not identify itself as UISUBCLASS_MIDISTREAM, and does not supply standard descriptors that specify the jack mappings. It has a generic USB interface descriptor so you can learn it has five endpoints, at addrs 2, 4, 81, 82, and 84, but as for what those endpoints are for, well, that just has to be known to the driver by entries in the quirk table. As it turns out, the output ports are split even/odd between endpoints 2 and 4, all data from both input ports appears on endpoint 81, and I haven't the foggiest idea what 82 and 84 are meant for. :) The other weird thing about this device is that you can send data for any of the four output ports to either endpoint 2 or 4 and the data will go to the right port regardless ... but if you're not using the designed endpoint for that port, flow control doesn't work. Of course this device is just one example of a nonstandard USB MIDI device; other devices if nonstandard could be arbitrarily different, and the current quirk macros are just what's sufficient to handle the currently supported quirky devices. > currently, the midi(4) driver parses data as-is to the user-land, supposing > that the user application have to decode (and thus to check for > inconsistencies) the input stream. Inside the kernel, input midi stream is > parsed only if the sequencer is opened and output stream is parsed in the > umidi(4) driver in order to build packets. As you can see, I've taken the approach of concentrating the midi parsing in midi(4) and removing it from umidi(4) and the sequencer, and providing some guarantees that can simplify the user application as well. Though the MIDI protocol is pretty simple, the special cases for running status, system common and realtime messages, and note-on/note-off equivalence make it just tricky enough that incomplete/incorrect implementations are common (for example, the state machine in umidi would build incorrect packets if a realtime message appeared interleaved with a longer message). So it seemed a good idea to centralize that functionality. It's now done in a finite state machine with 20 states, only 3 bytes of side storage, and very few loads/stores/compares on most paths, so the cost of doing it in kernel is quite small. A benefit for the user application is that all reads from the rmidi device are in canonicalized form, realtime messages cannot appear within other messages (except sysex) and as long as the read request is big enough for at least one complete message, every read will end at a message boundary so the user app does not need to parse across read buffers. This will not adversely affect applications that already do such processing, but can be less likely to expose bugs in them. Protocol errors found by the state machine are counted using event counters (readable with vmstat -e) - on the input side that can be quite useful in diagnosing either electrically poor connections, or faulty low-level drivers. On the output side, write(2) will return an error if invalid MIDI is written - this may expose bugs in applications that generate MIDI streams, but that's the idea. Another reason for centralizing the message assembly and moving it out of umidi(4) is that other transports for MIDI over other media are being defined, such as MIDI over 1394, and they will be likely to need the same functionality. -Chap