Thread: WARNING, can't assign realtime scheduling to thread!

[prasadbrg]

Hello everyone,
I'm running Ubuntu Jaunty 9.04. Till recently, my linuxsampler setup on this particular system was working without (major, noticable) glitches, i.e very few xruns and not many dropped notes. Since the past few days, however, I'm seeing a host of xruns and buzzes and drop notes. I tried switching to the RT kernel (kernel 2.6.28-3-rt, via synaptic). The result - a *huge*, unmanageable latency. I also noticed this warning which I'd not seen before:

Code: Select all

Thread: WARNING, can't assign realtime scheduling to thread!

I'm using jackdmp 1.9.4, compiled from source:

Code: Select all

/usr/local/bin/jackd -S -R -dalsa -dhw:0 -r44100 -p256 -n2

Incidentally, here's what 'top' reveals: (Note: these are with the
vanilla kernel).

Code: Select all

 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29516 guru 20 0 35872 13m 10m R 10.3 1.4 0:28.17 qsampler
29503 guru 20 0 437m 436m 76m S 2.7 46.5 0:11.57 linuxsampler
29493 guru 20 0 88632 74m 72m S 2.3 8.0 0:11.20 jackd

No user-owned entries have RT priority, but down the list some
root-owned processes do, for e.g:

Code: Select all

3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0

All user-oned processes have the same priority: 20
My /etc/security/limits.conf file ends with this:

Code: Select all

@audio - rtprio 19
@audio - memlock unlimited
@audio - nice -19

And I'm a member of the group 'audio'.

I'm sure there are better realtime kernels out there, but before I switch the kernel, I'd like to understand why exactly linuxsampler is not being allocated realtime priority. I don't know much about this. Can someone help me out with this?
Thanks in advance!
Cheers,

Guru

[Alex]

Your rtprio setting is too low. It looks like you added the nice setting instead. it should be closer to 99, not 19.

On a wider note.....


When you choose a kernel, the interlink is your friend, and google is your buddy. From kernel number 2.6.27 onwards, there have significant changes that have directly affected audio performance. This goes for ALSA too, as the alsa team switched from rtc timer to hpet timer somewhere around version 1.0.18. So the marriage between significant kernel, and ALSA changes, has been near divorce on more than one occasion. Kernels from 2.6.29 onwards, up to 2.6.31, coupled with ALSA 1.0.20 onwards, seem to have stabilised a bit, and you might get luckier with this sort of combination.

The same is true for JACK. It's gone through some significant changes, and as a result, 0.118.0 upwards for jack1, and 1.9.3 upwards for jack2 (jackdmp) are sort of transitional, again depending on the kernel/ALSA combination you're using.

This is complicated further in mainstream distros, with the compulsory inclusion of pulseaudio, which needs battering with a fair deal of work, and a large hammer, to have it play nicely with JACK.

The threading problem you're having is more likely than not, a problem with your JACK/kernel/alsa build, and not Linuxsampler. You don't seem to have JACK running in realtime.

I don't use Jack2 (jackdmp), so i can't offer any help there, but for what it's worth, i'm using Gentoo64bit with fluxbox, jack1 0.118 (svn), a 2.6.31-r6 RT kernel i complied from vanilla, and ALSA is 1.0.20. Linuxsampler behaves well with this particular combination, and i have it running with JACK RT, all day every day. I'm not sure which kernels you are offered by Ubuntu, but anything below 2.6.29, from the research i did when sorting mine out, is going to be more problematic, judging by the trainwrecks in various fora.

Finally, the JACK options changed a short time ago. You no longer need to use the -R flag when starting JACK in RT mode, so if you're doing this, you can leave it out. (it's realtime on by default now)
You should also be aware that there's quite a few users that have reported pretty sound results using a non RT kernel, although the latency is understandably greater.

I wish you luck. Sometimes the excitement of upgrading can result in a sacrifice of stability. I've made this mistake too, and in the past have gone back to a stable and proven setup, with older versions to get music written, and not spend all my time sorting out problems.

Alex.

p.s. going through your jack config options, i noticed you're running -n2 for number of periods. have you tried this with 3?

[prasadbrg]

Alex, that's a very informative reply. It answers many questions that I've had for quite some time now... thanks a lot!
I spent quite some time trying to find the solution myself by trial and error.... Around the same time you were writing your post, I happened to hit on the solution for the realtime issue:

Code: Select all

@audio          hard    rtprio          50
@audio          soft    rtprio          30
@audio   -  rtprio     100
@audio   -  memlock    unlimited
@audio   -  nice      -19
# End of file

This ensures that the "can't assign realtime scheduling...." warning goes away.

But the xruns remained. To cut a long story short, I found the source of the problem: a python script I've written was screaming dozens of warning messages per second, and since it was auto-launched thru' qjackctl, the qjackctl message window was spiking the cpu usage. Close the messages window, and the xruns dissappear. I've checked and re-checked this for about 2 hours now....! And yes, I'd edited the python script a few days back, which coincides with the start of the xrun issue.

End result: extremely infrequent xruns , with 5.2 ms latency, on the vanilla kernel. BTW, this is an old celeron laptop with 1 gig ram... I am *extremely* impressed with linuxsampler's performance. Also, on the same system, jack used to frequently crash, specially whenever CPU usage would spike. Jackdmp is remarkably resilient to these crashes.

I'm left with this rather naive questions:

• in a realtime priority kernel (assuming things are working as they should ) would the above python script still cause xruns?
• Put another way, since the python script (or any other process that causes CPU usage to spike) and linuxsampler are both started by the same user, do they get assigned the same priority?

Essentially, I'm ignorant of how exactly linuxsampler gets a higher priority over any other process (I had naively assumed that all processes by a user who is member of the 'realtime' group get the higher priority...!). I would appreciate it if someone could help me out in this regard. My ultimate objective is to ensure that no other process can spike the cpu and cause xruns in a live performance .
Cheers,
Guru

[Alex]

I'm no coder, but if a python script was messing up my apps, it'd be the first thing to go.

And by process of elimination, if you changed your script, and then watched your system start to crash and burn, one leads to the other, yes?

I don't know how linuxsampler priority is allocated, but i have learned that setting jack properly makes a lot of pain go away, if you can call that a definitive assessment. (Hey, it works for me.) If any process shares priority, and it's prone to spikes, then it seems to make sense that other apps are going to be affected too. I've found this with a couple of apps who get the cpu screaming while they start up, or "do something', and if any of the other apps are in anyway fragile, they tend to fall over, more often than not (Linuxsampler is the exception for me, it just keeps going unless i do something really stupid.). you seem to have your evidence in front of you, that the python script in its current form isn't going to play nicely.

Any reason why a BASH script, or a small collection of BASH scripts wouldn't fulfill your scripting requirements? Might be worth considering.

Anyway, good to hear you're off and running again, and i assume from what you've written that python script aside, your system is working fine again. If you can post versions of kernel, jack, alsa, etc, for your now decent working setup, it might help others who come for advice.

Onwards and upwards.....

Alex.

p.s. I don't use qjackctl at all, as in the past, it's messed things up for me,with variations in cpu use. Maybe there's a clue there too. It's always been, and still is my intent, to run as few GUIs as possible, and use terminal tools like jack_connect (as an example) instead. I'm not sure how your setup would fit with this, but if a good portion of it, in terms of port allocation (another example) is fairly static, then maybe a simple BASH script can help here too, and negate the need to run a jack frontend at all, thereby removing another potential source of CPU angst.
Worth thinking about?

[prasadbrg]

I'm no coder, but if a python script was messing up my apps, it'd be the first thing to go.

Alas, the python script (it's more of a full-blown application, with a nice GUI... ) is the heart and soul (brains is more appropriate, though less poetic) of my live setup. It functions quite like Apple's Mainstage, in that it gives me quite flexible mapping solutions for my hardware controllers...

... anyways, I debugged and silenced the script, so that's taken care of.

If you can post versions of kernel, jack, alsa, etc, for your now decent working setup, it might help others who come for advice.

I just finished building a 2.6.31.6 RT-preempt kernel (thanks to Jonathan E. Brickman for the instructions on his blog). Also compiled Alsa 1.0.21 from source (1.0.20 didn't detect my USB midi keyboard.. but I can't rule out a compile error on my part). I've retained Jackdmp 1.9.4.

After my initial fiddling around with priorities using the 'chrt' command, I find that Florian Paul Schmidt's recommendations for a priority of 70 for jackd work quite well. However, I felt there was a noticable decrease in xruns after assigning a slightly higher priority (~80) to Linuxsampler.

Does this observation make sense? And now, I'm curious....what priority values do the good folks who use LS regularly on RT-preempt systems use?

I look forward to your recommendations!
Cheers,

Guru