> I think this is much harder than you think :) Most MIDI devices cannot > tell you when MIDI data will be delivered to the wire. Even the at the > hardware level, there is a (small) FIFO that buffers between the > device driver and the UART chip. On decent hardware, this tends to be > 8-16 bytes long, which represents 3-5 NoteOn/NoteOff messages and > about a few msecs of real time.
I don't think it would be at all that usefull for the MIDI API to give the actual trasnmission time for events back to the application. It is not even possible as you already mentioned. I was talking about a best effort 'sent at this time' scheduling. Now why would this be in the API I hear you ask :) Because... > My own approach to this has tended to be to deliver data directly to > the device driver (i.e. do not use a "sequencer" layer) at my best > approximation to when it should be delivered to the wire, and assume > that the device driver and the hardware will work hard to do the best > they can. > > Notions of time are best handled entirely in an application, as far as > i can tell. I don't want an external system to try to deliver my stuff > "when it is supposed to" unless "when" is "right now". The system's sense > of priorities and so forth might be very different to what I want. ...using the driver directly is a problem. Writing support for serial MIDI interfaces is, as far as I can tell, unnecissarily difficult. So a library is better. It would not really need to do scheduling also but this would enable much better timing on professional mulitport serial/usb MIDI interfaces, since in order to send MIDI messages on all ports at the same time they will have to be sent ahead of time. > >I also think that MIDI should be kept seperate from audio (ALSA) as much as > >possible. That a lot of soundcards have an onboard MIDI interface is more an > >implementation detail IMHO. > > But ALSA is a MIDI API as well an audio API. it contains 2 different > MIDI APIs: the sequencer, which is more like the one you're talking > about, and the rawmidi API, which is what you'd probably base yours on > top of. For the same reason as mentioned above I can't implement the API on top of rawmidi and that is also my problem with the ALSA sequencer (that and the fact that it is in the kernel). > >> JACK has an interrupt-cycle-resolution UST source (at least when used > >> the existing ALSA PCM driver). It could easily add the cycle counter, > >> but that doesn't make any sense given the clock skew that I alluded to > >> above. > > > >Can it give a mapping of cycle counter and the JACK media clock? > > it could do, but it doesn't. there is no portable way to read the > cycle counter. the RTC is considerably more portable, but you need > root or CAP_RESOURCE to set the frequency. So we'll just have to make sure Linux gets CLOCK_MONOTONIC, because it is needed for media applications. --martijn
