Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: ma loka 11 1999 - 14:35:54 EDT
On Fri, 8 Oct 1999, Paul Barton-Davis wrote:
> First, any program that only does I/O to /dev/midi should be shot at
> dawn. If it uses a user-selectable one of /dev/midiNN, it can live.
Why not just let the user type in a damn filename (fifoname)? It's
actually _easier_ to code, after all. You can always make it default to
the common case.
> (clever workaround appreciated, but deleted here)
> Alas, FIFO's don't work exactly like files, devices or sockets. If you
> do the open...read and open...write sequences in the wrong order
> and/or without the correct logic, you will get errors instead of
> blocking.
I ran into this problem with my FIFO-based MIDI toys. The trick I
discovered was to put the open calls in a busy loop, using nonblocking
mode. Once both ends are connected, you can fctl them back into blocking
mode. Too bad there's no equivalent of select for open.
> Also, the beauty of this kind of scheme is one of the things I have
> against the ALSA lib API for raw MIDI devices. Anything that tries to
> obscure or complicate the fact that a MIDI "port" is just a byte sink
> and source is evil :) Thats why I never use the ALSA lib API for MIDI,
> but just stick to regular Unix open/close/read/write on /dev/snd/midiCxxDyy
Agreed. Majorly. I don't mind wrapping a nice API around the device as
long as I always have the option of writing to it raw. Can't really
complain about ALSA though, since it supports both.
On a related note, why aren't the advanced features of sound cards (in
particular, patch dumping) performed through sysex commands rather than
ioctls? It seems a natural to me to keep everything inband.
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST