Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon Aug 19 2002 - 19:21:29 EEST
Martijn Sipkema wrote:
>> 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.
Yep.
I'm not so sure that the impact will be low, caching is essential to
computing speed for all I know.
>MIDI through and any other 'immediate' type MIDI messages do
>not need to be scheduled, they can be written to the interface immediately.
Yes, they could. It would however necessitate different input routes
for 'immediate' and 'queued' events to the MIDI output handler. This
would not help make things simpler. It would also mean that a Sysex
or pitch/CC burst routed through can delay MIDI clocks because of the
limited bandwidth on the MIDI wire.
Thinking about it -- it's hypothetical because we don't have them in
Linux yet -- I believe a decent MIDI out handler using a firm timer
would be an order of magnitude more complicated than one based on the
RTC. Have you coded one yet?
tim
This archive was generated by hypermail 2b28 : Mon Aug 19 2002 - 19:24:15 EEST