Subject: Re: [linux-audio-dev] high level midi api
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Oct 29 2001 - 13:23:24 EET
>ok, but the callback is called at the time the event is to be sent right?
>so it wouldn't be possible to send some data to an interface early and
>have the interface transmit them at the correct time?
there's no support for any h/w right now that can do that. if and when
ALSA gets specs for such h/w, i would expect to see the sequencer
modified to permit "passthrough" of such data to the h/w so that it
can do its own scheduling. its non trivial though, since the h/w
almost certainly has less buffering capacity than the host
system. what happens when you queue a 1MB MIDI sysex event (i've done this)?
>i know. i would like to have a high level midi api that uses events and
>a timestamp. but no support for tempo, mtc, midiclock, etc. only one
>time (like openml's ust). and that the scheduling of the events can be
>done in the driver. and some way to deal with streams of midi data
>(sysex) should be provided.
the ALSA sequencer does all this.
>i think the sequencer should be in user space (and in the application). all
>the application needs is.
>- a function to receive midi events with an accurate (<< 1 ms) timestamp.
check. ALSA does this. the resolution of the timestamp is
user-controlled, and it depends on the time source you connect to.
>- a function to send midi events with a timestamp, the driver transmits
>the event at the specified time. events have to be sent in the correct
>order.
check. ALSA does this, and doesn't require that events are sent in the
correct order.
>- functions for flushing and draining.
check.
>- maybe a function for 'out of band' events. (for midi through).
check.
>- some way to send/receive sysex.
check.
>- and a way to get the time (the same used for stamping/scheduling).
check (i think).
there are actually two parts to the ALSA sequencer: a router and a
scheduler. the router needs to remain in kernel space so that it can
talk efficiently to various clients, both in kernel space and user
space.
but i agree that the scheduler should be in user-space, if only so
that it can be more flexible. as i said, people involved in writing
the sequencer (primarily takashi these days) have indicated that they
also agree with this, but its a large task to move it out of the
kernel and to split the routing/scheduling parts up. its also
debatable whether it should be a daemon handling scheduling for
multiple clients, or a shared library invoked by each client. there
are advantages to both of them.
--p
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 13:21:35 EET