Subject: Re: [linux-audio-dev] [ot] rawmidi && alsa
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Apr 24 2001 - 17:49:00 EEST
>Yes, it could be implemented (and we'll implement it), but I don't
>recommend to use it. The much better behaviour is to control the output
>buffer (to see, how many bytes were not transmitted) rather than block a
>process.
Why ? If I try to write a large chunk of data to the parallel port, I
expect to block. The same applies to serial ports. I don't think it
wise to try to make a MIDI port look like a Unix filesystem, with a
buffer interposed between user space and the hardware. Of course, for
some hardware, there needs to be a buffer, but thats an implementation
detail specific to the hardware.
>> > (ignoring O_NONBLOCK, etc.). the concept of "drain", "drop" etc. don't
>> > have any place in the way i think about "raw MIDI". whats the status
>> > of a UART delivery bytes to a wire ? there isn't one, other than a
>> > permanent error. i am not sure how these crept into the alsa API. they
>> > certainly belong in the sequencer API, but raw MIDI ? i don't think so.
>
>I'm sorry, but this layer is required in my eyes and it's always better,
>if ring buffer could be gained for some really fast hardware (I don't
>think that we'll have only serial MIDI connections with the end devices).
>Imagine USB or FireWire or some other hardware transport layers.
What possible difference do they make? The whole point of using
rawmidi is to skip the temporal scheduling done by the
sequencer. Therefore, if I call write() on a raw MIDI file descriptor,
it means I want to deliver the data now, or at least ASAP. It doesn't
many any difference to me if the data transmission speed is 100MB/sec
or 32kb/sec.
--p
This archive was generated by hypermail 2b28 : Tue Apr 24 2001 - 19:19:31 EEST