JACK and realtime process scheduling

[jonaswidarsson]

So we all know there are issues with realtime process scheduling.

Right now I am listening to mp3 through Juk. Arts is running setup to interface with jack. It works almost completely. The buffer is:

configuring for 48000Hz, period = 1024 frames, buffer = 3 periods

Realtime scheduling is on (emerge realtime-lsm), according to lsmod and that jack wouldn't start with the -R option if I rmmod the realtime module.
Any time the hard disk is accessed too much the sound is interrupted.

I don't know if I get the maths right but if I say (1024 * 3 / 48000) = 64 ms.
That's a rather large latency, given the purpose of jack... Still it interrupts now and then.
qjackconnect says the CPU load is around 1.00. I guess that means 1%. I watched it go up to around 51.00 before, so it oughtta be percents.
such a low load sounds nice, but still it doesn't work very well.

I am trying to find a kernel and jackd setup that works in all cases. It is not an easy task.

I was on gentoo-sources (2.6) up until tonight when I read this from the kernel guide:

ck-sources is Con Kolivas's kernel patch set. This kernel is HIGHLY tuned for desktop performance at the expense of throughput and some of the scheduler's ability to prioritize applications.

ck-sources and gentoo-sources are not equal, but I read sometime about a year ago that gentoo-sources had very similar, if not equal scheduling patches.

So tonight I went for the vanilla 2.6 kernel, to get rid of the desktop scheduling patches.

Now everything is a lot better, but sporadic disk accesses still cause big interrupts in the music.

Questions:
How should a linux PC be setup to get the most out of jack with a 2.6-kernel?
Is there any kernel patch out there that deals with this issue alone?

[schnake]

Hi,
just in case you still have not found what you're looking for...

First you might have a look at JadeX sources ( http://forums.gentoo.org/viewtopic-t-320611.html ). Just stay away from using reiser4 (see http://bhhdoa.org.au/pipermail/ck/2005- ... 02389.html although this may have been fixed by now). I did not yet try that patchset myself by now.

Morph-sources ( http://morph-sources.sf.net ) used to have Ingo Molnar's "Realtime-preemption" patches too, but no longer for 2.6.11+. I had quite good results (32 frames * 2 periods @ 44.100Hz on 1 GHz Thinkpad, no XRUN) with the 2.6.10-morph23 "Lady Pres" version IIRC.

Also keep in mind that running through ARTS adds latency, and can be responsible for drop outs too (if the ARTS buffers are to small).

[jonaswidarsson]

Hi,
just in case you still have not found what you're looking for...

First you might have a look at JadeX sources ( http://forums.gentoo.org/viewtopic-t-320611.html ). Just stay away from using reiser4 (see http://bhhdoa.org.au/pipermail/ck/2005- ... 02389.html although this may have been fixed by now). I did not yet try that patchset myself by now.

Morph-sources ( http://morph-sources.sf.net ) used to have Ingo Molnar's "Realtime-preemption" patches too, but no longer for 2.6.11+. I had quite good results (32 frames * 2 periods @ 44.100Hz on 1 GHz Thinkpad, no XRUN) with the 2.6.10-morph23 "Lady Pres" version IIRC.

Also keep in mind that running through ARTS adds latency, and can be responsible for drop outs too (if the ARTS buffers are to small).

Arts:
Yes I realise that...

I haven't made much progress since I posted but I recieved a link from Florian Schmidt that was really useful.
I was running the jack fifo's on disk instead of in /dev/shm and changing that was a BIG difference.
here it is:
http://www.affenbande.org/~tapas/wiki/i ... ux%202.6.x

And I DO use reiserfs: Everywhere... I Hope any such issues are solved by now.

I will look further on the topics you mention later, as I am at work now.

Thank you.

[schnake]

BTW, if you just want to listen to some audio that is beeing produced entirely within your computer (e.g. play some OGG files) you do not have that high demand on low latency (= small buffers). Just make them big enough (say 1024 frames * 3 buffers) and even a recent vanilla kernel should be able to do that without XRUN's (of course you still need realtime-lsm to allow jack to run with realtime privileges as non-root).

You may e.g. notice a small lag between starting/stopping the player and the sound starting / stopping, but that's not a big deal, is it? And as long as you stay inside your computer (e.g. record your players output via jack to ardour) latency basically is a non-brainer.

As soon as you have audio "enter end leave" your computer and interface with some external gear latency will be important. But only then.

I just wanted to point this out, since a lot of Gentooers seem to suffer heavily from a profound "ricer-phobia" nowadays as soon as someone dares to discuss anything performance related

[jonaswidarsson]

I am interested in writing a KDE application meant to help me when I excercise with my musical instruments.
That involves recording + processing + mixing and output, so I would say I need the low latency thing.

Otherwise, for simple playback I am happy without jack and running just arts on alsa instead.

[schnake]

That involves recording + processing + mixing and output, so I would say I need the low latency thing.

Yes, you do.

My comment was targeted at those who seem to fight the realtime preemption patches by simply dening that there may be a valid reason someone could want low latency. By all means I welcome any honest discussion on how that could best be achieved technically (and wether it is at all appropriate for a "main stream" kernel), but I got the impression those who express a reasonable need for low latency are often globally attacked as being "ridiculous ricers" here. I think that's quite a decline in culture, and really a shame for this fine forum

Oh, recently there was a poll on this topic here (something like "Realtime preemption: shit-hot or hot air"), but I can not manage to find it again.

Ok, enough rant for the next 3 months

I am interested in writing a KDE application meant to help me when I excercise with my musical instruments.

Good luck and have fun.