Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Tue Feb 26 2002 - 23:27:24 EET
> >In order for events to be transmitted on multiple ports at the same time
> >they will have to be buffered in the interface.
>
> this is simply not true. if you have N MIDI hardware devices each with
> empty FIFOs, you can deliver the data "simultaneously" to them with
> ALSA. the only things that interfere with this are the FIFOs not being
> empty, and the time it takes to push the data to each device. Since
> this time is way under the transmission time for a single byte, its
> effectively simultaneous.
I don't think you understand what I mean. Say I have an Emagic AMT 8
connected to my rs232 serial port (at 115kbaud) and another AMT8
daisy chained. the serial port FIFO is empty. I now want to a note on
message (3 bytes not using running status) to every port on both
interfaces. This is 3 bytes for the first port, 5 for the second (3 for the
note on plus 2 for a channel change), 5 for the third and so on. Sending
the first 15 note on messages will take 14*5 + 3 = 73 bytes. With
115200 / 10 (1 start, 8 data and 1 stop bit) = 11520 bytes per second
a byte takes 1 / 11520 = around 87 microseconds. Thus the transmission
of the first byte of the last note on is delayed 73 * 87 = 6,3 ms. With a
chord this will be even larger and it can be heard. The delay isn't constant
which make it easier to become a problem. This delay can be reduced
when the events are known and sent in advance to the interface and
transmitted by the interface at the correct time.
Note that this problem only occurs with multiport interfaces connected
using a single relatively low speed serial link. Also this is because a
message
has to be sent atomically and not byte for byte so it is not possible to
first
send a single byte to all ports.
So you see this problem can only be solved by having the interface store
and schedule messages (or use a very fast link to the interface, which
would be a much simpler solution, but it is not what the hardware
developers do).
> > Both Emagic and Steinberg
> >interfaces do this.
>
> there's no magic in those devices. thankfully, their european origin
> has not led to a patent on their exceedingly obvious idea. you might
> think they have done something really clever, and although neither of
> us can really prove it one way or the other, i am firmly convinced
> that all they've done is put a few more brains inside the box. all the
> brains do is stuff that a Linux system with multiple ports could do
> too: buffer the data, deliver on time. they've packaged it in an
> attractive, compact package. thats nice, but its not clever.
As explained above, the slow serial link to the interface is the
bottleneck.
> >> obviously, if you queue too much data to be delivered all in same
> >> 1msec, it will back up, but there's no way around that - its a
> >> function of the wirespeed. this is fundamentally what the scheduler in
> >> the existing ALSA sequencer does, what SoftWerk does etc. but we don't
> >> have a clock with the correct frequency.
> >
> >I don't think a clock is needed for MIDI. An event can start at any time.
> >There is no clock on a MIDI wire.
>
> there absolutely *IS* a clock. its built into the UART chip that
> converts the digital data into an analog representation on the
> wire. it runs at 31.25kb/sec. you can't deliver data to the wire "out
> of sync" with that clock.
But transmission can start at any time. Then it is transmitted with a number
of state changes per second on the serial line (baud).
> >The operating system should support accurate scheduling though, at least
> >1 millisecond clock resolution. With Linux this is 10ms at the moment on
> >i386 IIRC and that is not acceptable.
>
> You do not need to limit yourself to the OS system timer. You can use
> the RTC to get timing with a resolution down to about 0.1msec, and you
> can also use the interrupt from an audio interface to provide timing
> on the order of 1msec.
>
> The ALSA sequencer as well other programs that use the RTC (MusE,
> SoftWerk) do this kind of thing already (though the sequencer requires
> a kernel patch to allow it to use the RTC).
Using the RTC is not portable. CLOCK_MONOTONIC should provide
what I need. Maybe I'm not using audio, so using the audio clock is not an
option, and I want the audio and MIDI API seperated apart from a single
common clock.
> >> ALSA would like to support these devices. Therefore, you can "expect"
> >> to see the ALSA rawmidi API extend to provide access to early
> >> transmission. This would be hidden inside the ALSA sequencer's
> >> operations for apps that used the sequencer.
> >
> >I agree. But if extending the ALSA rawmidi API is the right way to
achieve
> >this I'm not sure.
>
> Why not? The API seems fairly simple to me:
>
> /* Like snd_rawmidi_write(), but used for raw MIDI devices
> that claim to support queuing. Returns EINVAL if the device
> referenced by the handle does not support such operations.
> */
>
> snd_rawmidi_queue (snd_rawmidi_t *handle, char *data, size_t bytes,
> snd_rawmidi_time_t when_to_deliver);
>
> the hard part is defining the timebase to use, though the
> microsecond-based one returned by gettimeofday() doesn't seem like a
> bad place to start.
gettimeofday() is not unadjusted. UST is needed. And indeed the API
shouldn't be overly complicated. Still I think It is good to keep it
seperate
from ALSA and to have some things done slightly different from the ALSA
rawmidi API.
> if the buffering scheme used by the sequencer was moved into user
> space, this would become trivial to write, even for devices that do
> not support queuing.
My API will support this too. On the other hand, the sequencing of events
that do not arrvive in timed order is not really trivial to implement for
real
time, the memory management will get harder, so my API won't support
that.
--martijn
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 23:18:25 EET