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

Florian Schmidt mista.tapas at gmx.net
Fri Dec 30 16:04:24 UTC 2005


On Fri, 30 Dec 2005 15:17:04 +0000 GMT
"Chris Cannam" <chris.cannam at ferventsoftware.com> wrote:

Hi Chris,

> > and midi events are not queued
> > for future delivery but always delivered immediately.
> 
> but this isn't -- Rosegarden always queues events 
> from a non-RT thread and lets the ALSA sequencer
> kernel layer deliver them.  (Thru events are delivered 
> directly, with potential additional latency because of
> the lower priority used for the MIDI thread.)  In
> principle this should mean that only the priority of
> the receiving synth's MIDI thread is significant for 
> the timing of sequenced events.  

Hi, 

i tested Rosegarden running with the system timer as timing source (RTC
is a bit broken atm on -rt kernels for me), and i do not get
satisfactory results. I used my ughsynth again (which is heavy on the
cpu which makes the problems just clearer) with its midi thread at
priority 95.

Here's example output with rosegarden producing a supposedly steady
stream of 16th notes at 120 bpm:

note on, frame_time: 205200106
next event: 744
next event: 746
diff: 5998
note on, frame_time: 205206104
next event: 599
next event: 600
diff: 6042
note on, frame_time: 205212146
next event: 497
next event: 498
diff: 6157
note on, frame_time: 205218303
next event: 510
next event: 511
diff: 6140
note on, frame_time: 205224443
next event: 506
next event: 507
diff: 6145
note on, frame_time: 205230588
next event: 507
next event: 508
diff: 5511
note on, frame_time: 205236099
next event: 898
next event: 899
diff: 6000
note on, frame_time: 205242099
next event: 754
next event: 755
diff: 5998
note on, frame_time: 205248097
next event: 608
next event: 609
diff: 6034
note on, frame_time: 205254131
next event: 498
next event: 499
diff: 6153
note on, frame_time: 205260284
next event: 507
next event: 508
diff: 6141
note on, frame_time: 205266425
next event: 504
next event: 505
diff: 6148
note on, frame_time: 205272573
next event: 507
next event: 509
diff: 5521
note on, frame_time: 205278094
next event: 908
next event: 910
next event: 510

which is again in the range as with my test program and ughsynth having
a low midi thread prio. This is clearly audible, too:

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

this is the rosegardenfile used for this:

http://affenbande.org/~tapas/test16th.rg

This would imply to me, that either the way the events are scheduled in
rosegarden is buggy (unlikely as it works fine when there's less audio
load on the system) or that the event queue delivery by ALSA is somehow
happening with only SCHED_OTHER priority as well.

I have not yet found an option for ALSA to configure this.

>  - ALSA sequencer uses kernel timers by default and 
> of course they only run at 100 or 250Hz in many 
> kernels. 

In my case i have compiled the kernel to use a system timer frequency of
1000hz. It would be interesting to know though what priority the ALSA
event queue handling gets. 

I also stumbled across some problems with sleep() and especially waking
up when the sleep time has expired in the course of writing my
rt_watchdog program. Sometimes the high prio SCHED_FIFO thread wasn't
woken up as long as a lower SCHED_FIFO prio thread hugged the cpu even
when the sleep time of the high prio thread was long expired.. Ingo told
me back then that there's extra kernel threads for the timing subsystem
which need to be setup to high prios too for this to work correctly.
Haven't really investigated further into this.

I need to write another small test app that uses sleep based timing and
a high prio, too, to drive ughsynth. Will report what results i get.

>  - ALSA sequencer can sync to RTC, but the 
> associated module (snd-rtctimer) appears to hang 
> some kernels solid when loaded or used.  I don't have 
> much information about that, but I can probably find 
> out some more.

I have never bothered to try this either.

>  - ALSA sequencer can sync to a soundcard clock, 
> but this induces jitter when used with JACK and has 
> caused confusion for users who find themselves 
> inadvertently sync'd to an unused soundcard (the
> classic "first note plays, then nothing" symptom). 

> The biggest advantage of course is not having to run 
> an RT MIDI timing thread.  My impression is that this 
> aspect of MusE (which does that, I think) causes 
> as many configuration problems for its users as using 
> ALSA sequencer queue timers does for Rosegarden's.  
> 
> Any more thoughts on this?

>From my point of view just setting up a RT midi thread driven by RTC and
with a sufficiently high prio for dispatching midi events immediately is
the best way. As it seems to work well, at least for my small test case.

Further testing needs to be done though. I will report back.

I haven't really tried muse. Will do so if i find the time though..

Flo

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




More information about the Linux-audio-dev mailing list