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