Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Mon Aug 19 2002 - 18:04:45 EEST
[...]
> >User space MIDI scheduling should run at high rt priority. If scheduling
> >MIDI events is not done at a higher priority than the audio processing
> >then it will in general suffer jitter at the size of the audio interrupt
> >period.
>
> Jitter amounting to the length of time the audio cycle takes to
> compute, that is (which will obviously be less than the audio irq
> period in a usable configuration).
Yes, the audio interrupt period represents the worst case. But with large
audio
buffers and a jitter of say 70% of the interrupt period size this is still a
very
very large jitter and completely unacceptable (IMHO).
> Another reason to run MIDI behind audio: task switching and the cache
> invalidation it causes. If audio processing is interrupted 1024 times
> per second, audio performance *will* degrade, even more if many Jack
> clients (= separate processes) are involved.
>
> Not sure about the impact though. We definitely need some testing data
> here.
I think that the impact will not very high. Also, that is the price one has
to pay
for decent MIDI timing. Clearly, running MIDI at a lower than the audio
priority
will result in bad timing.
> >Using the RTC is not necessary when using firm-timers.
>
> If you're doing software MIDI through, you'll have to cancel the
> timer you've just set, which is bad. It gets worse when you have
> user functions that generate MIDI events at random. In this case
> I think the use of firm timers is not adequate.
MIDI through and any other 'immediate' type MIDI messages do
not need to be scheduled, they can be written to the interface immediately.
> >Also, when doing hard real-time audio/MIDI, it is not possible to use
> >more than about 70% of the available CPU time and still get reliable
> >results.
> >
> >Would a library for requesting the preferred scheduling policy and
priority
> >for a certain task be a good idea to improve cooperation between
> >applications?
>
> I'd leave it to the user, but I tend to expect a user to be savvy.
More likely it will be left to the developers of various different
applications and
cooperation between these applications might suffer as a result.
Instead a library for priorities could support the user to define his own
priorities
for various tasks, so a user would be able to choose if he wants to use a
high or
low priority for MIDI scheduling.
--martijn
This archive was generated by hypermail 2b28 : Mon Aug 19 2002 - 17:09:10 EEST