On Monday 22 December 2008, Sean Braithwaite wrote:
> Hello,
>
> I'm having more of problems running the latest (from svn) SC in terms of
> performance. I get a couple xruns per minute.The situation seems quite
> dramatic so i must have done something wrong. Here are the steps I have
> done to try and remedy the situation.
>
> - Installed the realtime kernel
> - Configure my limits.conf for @audio group to
> rtprio: 95
> nice -19
> memlock 256000
> - confirmed my user was in audio and audio owns /dev/dsp
>
> - Configure jack to use realtime,
> priority: 10,
> Frames/Period: 64
> Sample Rate: 44100
>
> - confirmed that sclang can run at priority 1
>
> Running off macbookpro 4.1 which ran SC fine under os x.
>
> any help would be greatly appreciated
When using a realtime kernel make sure that the apps for which you want realtime performance have priorities higher than all IRQ handlers except for maybe the soundcard's irq handler.
So usually the priority setup would look like this:
99 - Soundcard's IRQ handler
.
.
70 - jackd's priority (use -P 70 and don't mind that there are some other threads of jackd running at slightly different priorities)
69 - ScSynth (this will be done automatically by jackd if it was started with prio 70)
.
.
50-60 - All other IRQ handlers
.
.
.
1 - Sclang. You can start sclang at some other prio, but since scsynth doesn't know how to schedule with sample-precision without an OSC timestamp it's no use to give this a higher prio. You have to use timestamps anyways.
<rant>
Which brings me back to a previous point of me: Please make scsynth schedule into the next period with the correct offset when no timestamp is given. Since noone listens to me though, i can as well save my breath [why on earth would you want to _add_ jitter? Which is what one does if scheduling events at
period boundaries per default.]
</rant>
_The_ crucial point about the realtime kernels available in linux is that you can and _want_ to make sure you have the priorities of the processes in your system right. The big advantage over other kernels is that with RT kernels you can do this even for your IRQ handlers. Which is a vast improvement over non-RT kernels where it's xrun hell as soon as a single driver's IRQ handler decides to e.g. lock the big kernel lock, or simply busy wait for some time (as some network controller drivers like to do).
Not setting up the IRQ priority order correctly is also asking for trouble, since you _explicitly_ allow IRQ handlers to preempt your precious audio processing chain..
A nice tool to inspect priorities is htop. Play around in the options to
- not hide kernel threads
- not hide userland threads
then press F6 and sort for PRIO. To find out what device uses which IRQ use
cat /proc/interrupts
All this info is available in the web in more detailed form..
Regards,
Flo