Subject: Re: [linux-audio-dev] [ot] rawmidi && alsa
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Apr 24 2001 - 17:44:39 EEST
>> I've never seen a program that does raw MIDI I/O that would use any of
>> these. the (my) model of a raw MIDI device doesn't include any of
>> these concepts. when i write data to a raw MIDI device, i expect:
>>
>> * it either gets put on the wire immediately, OR
>> * my thread blocks until it can be put on the wire
>
>As far as I know, this is not true for current ALSA implementation. It
>seems you want an O_SYNC behaviour.
I wasn't precise enough. Let me restate:
* when viewed with ignorance about the details of the h/w
implementation, the data is put on the wire immediately, OR ...
Sure, I know that there's a bunch of crappy MIDI interfaces where
there may actually be a long delay between user space delivering the
data and it getting onto the wire. I consider that to be a problem of
using crappy MIDI interfaces. I've spend several parts of my life
applying my mind to solving problems with crappy hardware, and when I
look back on it, they're the most wasteful things I've done.
And sure, even with the best h/w, if I deliver too many bytes to be
written straight into the FIFO, I'm going to block. Thats fine. But I
don't want to have to consider a MIDI interface to be anything other
than a data port operating at a given speed. I don't want to know
about ring buffers, user space buffers, FIFO's, interrupts or anything
else like that. I give it data, it puts it on the wire, as soon as it
can. If I give it too much data, I have to wait for a while.
No O_SYNC in sight.
>> FIFOs, sockets and pipes provide the same thing, and the standard
>> syscall API works, whether the underlying MIDI device is supported by
>> an ALSA driver, OSS, or something else entirely.
>
>Low latency inet transfer using UDP and redundant transmit?
Oh, you mean you just reimplemented TCP?
>snd_rawmidi_fd_attach(NULL, &output, "name", fd, 0, 0);
>snd_rawmidi_stdio_attach(NULL, &output, "name", stdout, 0, 0)
Now thats what I call redundant.
snd_rawmidi_fd_attach(NULL, &output, "name", fileno(stdout), 0, 0);
is just fine.
You may recall that it was the snd_rawmidi layer that totally messed
up my ability to deliver 1.2MB of firmware to an ADAT M20. Why ?
Because there is this "hidden" user-space buffer that isn't part of
the clearly visible API. Why is there any user-space buffering at all?
When an app delivers 1.2MB of data to *any* MIDI port (without
O_NONBLOCK), it should expect to wait for several minutes. The driver
can enforce that. I don't see why there is any user-space
interposition for the rawmidi interface at all, and I generally find
that my programs are simpler and more reliable when I just use the
file descriptors directly, and avoid the rawmidi library code.
--p
This archive was generated by hypermail 2b28 : Tue Apr 24 2001 - 19:31:10 EEST