Subject: Re: [linux-audio-dev] high level midi api
From: martijn sipkema (msipkema_AT_sipkema-digital.com)
Date: Mon Oct 29 2001 - 23:55:58 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)?
sysex 'events' would have to be handled differently by the api since sysex
is more like a stream. for all other midi events scheduling is trivial. but
most 'intelligent' midi interfaces will probably not support sorting events
in their queue, their scheduling is only for short term i think.
given that the operating system supports getting an accurate unadjusted
system time and being able to schedule on that time (or at the very least
have midi events scheduled by the driver on it) makes implementing
a sequencer from user space possible. i did a quite accurate sequencer
engine for beos that could sync to midi clock with interpolating between
clocks with the beos midi2 kit. and the one thing that their midi api lacks
imho are drain/flush functions.
i think the emagic amt8/unitor8 have a 512kb buffer for sysex. what i think
might be a good solution is to be able to send midi events to a port and
when you need to transmit sysex you should be able to lock it and use it
as a stream.
i am not sure how to handle receiving a stream in an api. callbacks could be
a solution.
doesn't anyone agree that a better and simpler api might make a
/dev/sequencer
unneeded and would possible provide better timing?
> >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.
not as flexible as having the sequencing done in the application. it's nice
for
a midi player, but is it fexible enough for a complicated midi multi track
sequencer?
> >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.
i just think that the alsa rawmidi driver api is a little too low level and
the
sequencer too high level. i think it could be replaced by a single api that
is slightly higher level than rawmidi.
> >- 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.
that's what makes it too complicated. ordering the events can be better done
in the application.
> >- 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).
ok, where can i find the latest documentation for the alsa sequencer and
midi api?
> 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.
i'll have too read up on alsa, and i'll probably have to implement some
api to show what i mean.
--martijn
This archive was generated by hypermail 2b28 : Mon Oct 29 2001 - 23:00:19 EET