Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon Aug 19 2002 - 16:00:42 EEST
Martijn Sipkema wrote:
>
>> I find that for sending MIDI to an external device, "resolution = RTC
>> Hz" works very well. It is a problem that a realtime audio thread
>> 'suffocates' a RTC thread if low-latency is required, and only one
>> processor available. It's very hard to find a clean solution in this
>> case, but firm timers obviously do not address this particular
>> problem.
>
>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).
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.
>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.
>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.
tim
This archive was generated by hypermail 2b28 : Mon Aug 19 2002 - 16:00:27 EEST