Re: [linux-audio-dev] introduction & ideas

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] introduction & ideas
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue Feb 26 2002 - 21:58:14 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.

> 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.

>> 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.

>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).

>> 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.

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.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 21:49:24 EET