On Fri, 30 Dec 2005 01:52:10 +0100 Florian Schmidt <[EMAIL PROTECTED]> wrote:
> On Fri, 30 Dec 2005 00:47:46 +0100 > Florian Schmidt <[EMAIL PROTECTED]> 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
