Subject: Re: [linux-audio-dev] introduction & ideas
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Tue Feb 26 2002 - 03:51:45 EET
> 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
This archive was generated by hypermail 2b28 : Tue Feb 26 2002 - 03:40:28 EET