Today Jaroslav Kysela wrote:
>On Tue, 24 Apr 2001, Abramo Bagnara wrote:
>
>> Paul Davis wrote:
>> >
>> > >> there is absolutely nothing that i know of above read/write/open/close
>> > >> in the ALSA raw MIDI API that is of use to any application I have ever
>> > >> seen.
>> > >
>> > >No drop, no drain, no status, no avail_min, no buffer_size?
>> >
>> > 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.
>
>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. Many hardware is really broken for the MIDI transmits (imagine
>SoundBlaster with 2 bytes in Tx FIFO etc...). With O_SYNC you can't use
>the full bandwidth of the MIDI connection when the system is busy.
and, with O_SYNC i'd need a separate thread for MIDI output, or even
for every MIDI port the program uses if i don't want my scheduling thread
to block.
let's assume a problem case: i have MIDI clock messages (0xF8) to write
periodically to a device. in addition, a large sysex block needs to
travel down the same MIDI wire. of course, to be able to send both,
interrupting the sysex with the clock ticks, our program needs every bit
of knowledge about the port speed / buffer state. currently i am using
a userspace buffer for the messages, an assumed port speed and a periodic
writing function to get this right, but i don't really like this method
since it is just pseudo-sync by assuming things.
it would be great to be able to do this the right way, ie knowing the
exact port speed (MIDI, USB, 1394) and being able to make a correct
assumption on how much data can be written in the current cycle of the
MIDI scheduling engine. (or, if somebody has a better proposal to make,
please speak up.)
would this be possible with snd_rawmidi then, and how would it fare with
for example a standard 31.25 kbit MIDI patch bay connected via the much
faster USB or 1394?
>If you want to be more in sync with hardware, it's nothing simplier than
>to reduce the Tx ring buffer size to 16 or something around. Then, write()
>calls are blocked when the ring buffer size is full.
>
>> > if i read from it, then
>> >
>> > * i get data immediately, OR
>> > * i block until data is received from the wire
>> >
>> > (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.
if snd_rawmidi can solve the output timing problems by providing exact
control over the Tx buffer & speed, i have absolutely no objections to
its use; i'd rather be very happy to have more control over the MIDI
ports.
however, i know of nobody that got snd_rawmidi to work since 0.6.x. how
do you guys test the development of snd_rawmidi? is there example code?
finally, let me plea for keeping /dev/snd/midiCxDy accessible the way
we use it now because it's a simple and elegant unix method that has
stood the test of time. not every program needs the sophistication
that snd_rawmidi provides.
tim
------
To unsubscribe from <[EMAIL PROTECTED]> mailing list send message
'unsubscribe' in the body of message to <[EMAIL PROTECTED]>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs
