Subject: Re: [linux-audio-dev] midi events in jack callback (was: Reborn)
From: Paul Davis (pbd_AT_op.net)
Date: Fri Aug 16 2002 - 21:19:25 EEST
>Paul Davis 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
>>
>>why not just run the RTC thread at a higher priority? or does that
>>cause other problems?
>
>The problem is I write(2) MIDI from within the RTC thread; with the
>drivers/hardware we have I see no other way to ensure the bandwidth
>is used optimally and that MIDI clock is precise. (Sidenote:) That's
>also why I think firm timers don't help much; CC/pitch bursts must be
>fed to the interface that way, not to think of sysex.
>
>When writing to MIDI ports, some (especially the cheap) interfaces
>will block in kernel for generous amounts of time. Poll(2)ing for
>a write possible condition is not an option, on the AWE for example
>this can give up to 30% constant load in kernel. Ouch.
please learn what i consider to be an invaluable lesson: software that
uses cheap stuff to do cool things is great. software that tries to
cover up the flaws in cheap stuff is a waste of time. the creative
MIDI hardware is just so bad, its really pointless trying to make it
work like this. just use a card with a decent size FIFO, and then you
will find that write(2) will never block unless you are generating
more data than was received by the port.
>For these reasons, I haven't yet seriously thought of running the RTC
>thread at a higher priority, though now I think maybe my stance should
>be reevaluated?
from the perspective of the audio thread, it doesn't matter the RTC
thread blocks, in fact its arguably a good thing.
--p
This archive was generated by hypermail 2b28 : Fri Aug 16 2002 - 21:15:26 EEST