>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
