Re: [linux-audio-dev] Audio/Midi system - RT prios..

On Fri, 30 Dec 2005 01:52:10 +0100
Florian Schmidt <mista.tapas@email-addr-hidden> wrote:

> On Fri, 30 Dec 2005 00:47:46 +0100
> Florian Schmidt <mista.tapas@email-addr-hidden> wrote:
>
> [snip]
>
> Hmm,
>
> forget this post :) I need to do some more testing first..

Ok,

my synth was buggy (damn copy and paste). Now it works like a charm with
a setup as described in my original post. To illustrate the difference a
proper priority setup can make, here's debug output of my ughsynth
driven by the RTC based midi_timer note generator (links for both
programs at bottom of the mail):

note on, frame_time: 56249918
next event: 574
diff: 6071
note on, frame_time: 56255989
next event: 501
diff: 6144
note on, frame_time: 56262133
next event: 501
diff: 6144
note on, frame_time: 56268277
next event: 501
diff: 6143
note on, frame_time: 56274420
next event: 500
diff: 5500
note on, frame_time: 56279920
next event: 880
diff: 6000
note on, frame_time: 56285920
next event: 736
diff: 6000
note on, frame_time: 56291920
next event: 592
diff: 6054
note on, frame_time: 56297974
next event: 502
diff: 6145
note on, frame_time: 56304119
next event: 503
diff: 6142
note on, frame_time: 56310261
next event: 501
diff: 6144
note on, frame_time: 56316405
next event: 501
diff: 5517
note on, frame_time: 56321922
next event: 898
diff: 6001
note on, frame_time: 56327923
next event: 755
diff: 6000
note on, frame_time: 56333923
next event: 611
diff: 6035
note on, frame_time: 56339958
next event: 502
diff: 6144
note on, frame_time: 56346102
next event: 502
diff: 6143
note on, frame_time: 56352245
next event: 501
diff: 6144

The interesting number is the "diff" output as it tells us the
difference of the previous midi event timestamp to the current one.The
"next" field is the offset into the currently to-be-processed period. In
above output the midi handling thread of ughsynth ran with a priority of
59, which is below the jackd stuff in my system (-P 70).

Here's output with the midi handling in ughsynth running at a priority
of 95:

note on, frame_time: 71319937
next event: 385
diff: 6000
note on, frame_time: 71325937
next event: 241
diff: 6000
note on, frame_time: 71331937
next event: 97
diff: 6002
note on, frame_time: 71337939
next event: 979
diff: 6000
note on, frame_time: 71343939
next event: 835
diff: 6000
note on, frame_time: 71349939
next event: 691
diff: 6000
note on, frame_time: 71355939
next event: 547
diff: 6000
note on, frame_time: 71361939
next event: 403
diff: 6001
note on, frame_time: 71367940
next event: 260
diff: 6000
note on, frame_time: 71373940
next event: 116
diff: 6001
note on, frame_time: 71379941
next event: 997
diff: 6000
note on, frame_time: 71385941
next event: 853
diff: 6001
note on, frame_time: 71391942
next event: 710
diff: 6000
note on, frame_time: 71397942
next event: 566
diff: 6000
note on, frame_time: 71403942
next event: 422
diff: 6000
note on, frame_time: 71409942
next event: 278
diff: 6001
note on, frame_time: 71415943
next event: 135
diff: 6000
note on, frame_time: 71421943
next event: 1015

The difference is either 5999, 6000 or 6001 frames, which at a framerate of
48000hz is tightly around

1/(6000/48000) = 8 hz

which is exactly what the midi note generator is setup to do. The
variance is several orders of magnitude lower than in the previous
example output above with midi handling prio of 59, which does make an
audible difference:

http://affenbande.org/~tapas/stable_timing.ogg

as opposed to:

http://affenbande.org/~tapas/unstable_timing.ogg

To summarize here's how a well tuned -rt system for combined midi/audio
usage should look like (prioritywise):

99 System timer IRQ (you cannot change this anyways)
98 RTC IRQ
        
95
.
. Midi handling threads of softsynths/midi sequencers (preferably
.
85
        
82 Soundcard IRQ
        
80 Jackd watchdog thread
70 Jackd main loop
69 Jackd client (softsynths/midi sequencers) audio process callbacks
        
60
.
. Other IRQ handlers (disk, network, USB, GFX)
.
40

0 (SCHED_OTHER) All other software in the system

Sadly not many app authors are aware of this (as my unsuccessful quest
to get stable midi timing with available linux software showed), so i
hope this post does raise the awareness on the issue. It would be ideal,
if app authors allowed the user to finetune the realtime priorities of
each component of their software (well, especially the midi handling
part, as the audio processing priorities are determined by what priority
jack is given).

Here's the software i used for the test

http://affenbande.org/~tapas/midi_timer.tgz

http://affenbande.org/~tapas/ughsynth-0.0.3.tgz

Regards,
Flo

P.S.: i also summarized the results a little bit on this page:

http://tapas.affenbande.org/?page_id=40

Please let me know if there's any big errors on that page.

P.P.S.: Additionally to RTC or sleep() based mechanism (which relies
right now on the system timer frequency (which is a mere 250hz in
default kernels (easy to change to 1000hz though with a recompile))) the
future will also bring us POSIX high resolution timers. I don't know yet
how these will fit in exactly.

-- 
Palimm Palimm! http://tapas.affenbande.org