JackActivationCount::Signal - how to stop it?

[dewdrop_world]

Just switched to Jack2 for use with SuperCollider -- generally working great, apart from a large number of these messages in SC's post window.

Code: Select all

JackActivationCount::Signal value = 0 ref = 5

I've searched Google and I see a lot of references to this message, but nothing explaining clearly what it means and, more to the point, how to deal with it.

One thing I find confusing is that under Jack1, if I started the Jack server using qjackctl, Jack server messages would go into qjackctl's Messages window but not pollute SC's printed output. That's no longer the case -- the messages do appear in SC.

If they are harmless, is there a way to suppress them? I'm collaborating with a video artist and he gets very sensitive about spurious warning output -- and this will be especially sensitive since we had some xrun-kill-the-client issues under Jack1. He will see it and think Jack2 will fail us like Jack1 did. I'd really rather not have to explain this one.

Thanks,
James

PS I did try to search this forum for JackActivationCount, but the search feature doesn't allow key words longer than 14 characters! So no dice there.

[brummer]

that means your jack client take to long to get ready, try to set a higher priory to jack or / and use a higher frame buffer.

[dewdrop_world]

Okay... this is in my /etc/security/limits.conf:

@audio - rtprio 80
@audio - memlock 2883888
@audio - nice -10

And I am (of course) a member of the audio group.

However, jackd is starting with nice = 0 (why not -10?) and pri = 19.

ps x -o pid,ni,pri,rtprio,comm | grep jackd
1816 0 19 - jackd

Is that right? I can add a post startup script for Jack to renice it to -20.

Most of the time when I see these messages, it's when I hopped over to Firefox to look something up. I also see large CPU spikes for DSP being reported by qjackctl while Firefox is open, but hardly any of those at other times.

When my collaborator is running, most likely there will be nothing else happening on the machine, so maybe the chance of the message being produced is lower.

I'm a bit confused by one thing -- if it's the Jack client taking too long to provide a buffer of audio, why would it matter to adjust the priority of the Jack server? Shouldn't I renice scsynth instead?

James

[brummer]

The audio buffer used by a jack audio application is provided by jack, also jack set the prio for the audio/midi thread of your application. So when you give jack a higher prio, you give as a effect your app a higher prio.
And I didn't mean "nice", forget about "nice" when dealing with realtime prio, nice isn't touch the rt-prio stuff.
So nice 0 for jack is well. But pri = 19, that seems a bit low to me. most graphic cards run with 50, so they will disturb your workflow when you stay under this level , I use 89, for example.
Special when you have probs when you use firefox or other Stuff, a high prio for jack makes sure that the audio pipe will flow.

[dewdrop_world]

Thanks for the explanation.

Assume I've been on Linux for only about half a year and that I don't have a lot of experience manipulating process priorities -- that would be a correct assumption.

How do I bump up the rtprio?

I thought (from some web resources) that setting the audio group properties in limits.conf was supposed to do it, but obviously that isn't taking effect in my environment.

TIA,
James

[brummer]

You can setup the prio for jackd in Qjackctl for example, in the settings widget, the little spinbox. You need to stay under the settings you have in your /limits.conf so you could try settings like 60 or 75 first, before you change your limits.conf
When you change the limits.conf settings, you need to reboot to let PAM register the new settings.

Yea, it's a pity that you need to deal around with prio settings when you start to work with Pro Audio on Linux, anyhow, later you may find it comfortable that you "can deal with prio settings on Linux", this way it is high configurable and you be able to fit your System for any purpose well.

At the beginning it's a bit hard to understand, but here you will find a lot ppl how have done it already and help will coming fast mostly,

So welcome in the Linux Audio world James.

greats hermann

[dewdrop_world]

Great! Thanks for the specifics.

I looked at the Setup... box in qjackctl but somehow completely overlooked the one control for priority. Will try it later tonight.

I'm not frightened by any of this, by the way -- I don't mind getting my hands a bit dirty (though I do like to have some hints before trying something that could mess up the system). I've been around computers a long time and if I ask questions about things like this, it's because I want to learn.

Remarkably, even at lower priority, it's mostly glitch free. I should have switched to Jack2 along time ago...

James

[dewdrop_world]

Hm, wait, still confused. Starting manually at the commandline:

Code: Select all

/usr/bin/jackd -R -P56 -dalsa -dhw:0 -r44100 -p1024 -n2 -s
jackdmp 1.9.6
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2010 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 56
... the rest is normal ALSA connection stuff...

But ps still reports:

ps x -o pid,ni,pri,rtprio,comm | grep jackd
4528 0 19 - jackd

19? And '-' for rtprio?

Weird. Should I believe jackd's startup output, or ps? One or the other, or both, is wrong...

[brummer]

try this one

Code: Select all

ps -Leo class,comm,rtprio | grep jackd

jackd is multi-threaded, only the audio/midi thread run in the rt_class, so with the above command you used, you get the result for the non rt thread. I get same result with your command, here is what I get with my:

Code: Select all

ps -Leo class,comm,rtprio | grep jackd
TS  jackd                -
TS  jackd                -
TS  jackd                -
FF  jackd               89
TS  jackd                -

Also htop is a terminal program witch is a nice resource to have a look at running threads and there priori.

[dewdrop_world]

Ah, right you are, and the priority does show up properly now.

I'll run with this for a few days and see if it's better.

Thanks!
James

[thorgal]

hi James,

if you use jack2, use "jackd -S" in the QjackCtl setup (server name field).

[dewdrop_world]

Ah... "-S" appears to be a "magic fix" in several forum threads.

Precious little information online about exactly what synchronous mode does. I had thought I would need to avoid synchronous mode because it's "like Jack1" but I don't want xruns to kill the client like Jack1 did.

I'm running Jack2 now in synchronous mode (and further stressing it by hooking pulseaudio into it using falkTX's pulse-jack script -- I figure, if it works okay like this, it should be even better in a performance situation when I've disabled pulseaudio completely). There are occasional blips in the audio but clients are not dying, so it seems Jack2 in synchronous mode is less like Jack1 than the jackdmp readme suggests. [1]

Well, I guess really the bottom line is for me to run my system like this for a while and see how it behaves -- and if it's acceptable (as it is, so far), don't ask too many questions, don't sneeze, don't breathe wrong etc. But I'm curious why Jack2 in synchronous mode doesn't kill clients like Jack1. (That is, I'm grateful for a "magic fix" but I'm also suspicious of magic. I'd prefer knowing how or why it works. )

Thanks,
James

[1] http://www.grame.fr/~letz/jackdmp.html

"'synchronous' activation : in a given cycle, the server waits for all clients to be finished (similar to normal jackd)"

EDIT: PS - I do understand the difference between "synchronous waits for the clients to finish" vs "asynchronous proceeds whether or not all clients have finished." What's not clear to me is the difference in Jack2's synchronous mode compared to Jack1's xrun = instant death policy.

[dewdrop_world]

BTW, I'm still having large spikes. I modified the above ps command to show me every real-time thread. These (rather a lot) have a higher priority than Jack.

Is there a way to lower the priority of these system processes?

Thanks,
James

Code: Select all

ps -Leo class,comm,rtprio | grep -E [^-]$
CLS COMMAND         RTPRIO
FF  migration/0         99
FF  watchdog/0          99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
RR  rtkit-daemon        99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
FF  migration/1         99
FF  migration/2         99
FF  migration/3         99
FF  migration/1         99
FF  watchdog/1          99
FF  migration/2         99
FF  watchdog/2          99
FF  migration/3         99
FF  watchdog/3          99

[dewdrop_world]

But pri = 19, that seems a bit low to me. most graphic cards run with 50, so they will disturb your workflow when you stay under this level , I use 89, for example.

Incidentally -- http://ubuntuforums.org/showpost.php?p= ... ostcount=7

According to here and here, a lower rtprio value means a higher priority, so I think this setting is not the issue here.

So it seems I should have lowered the priority number in order to raise the effective priority.

Now running with rtprio = 2, and watching qjackctl carefully.

The spike appears to occur most often when the OS is opening a connection to a remote server -- usually I see it with HTTP, but I've also seen it when my IMAP client is trying to connect to the mail server. Strange that an activity that does not need to be real-time can interfere with real-time processes...

James

[brummer]

Now running with rtprio = 2, and watching qjackctl carefully.

The spike appears to occur most often when the OS is opening a connection to a remote server -- usually I see it with HTTP, but I've also seen it when my IMAP client is trying to connect to the mail server. Strange that an activity that does not need to be real-time can interfere with real-time processes...

Don't mix this stuff, may this site could en-light your mind a bit
http://subversion.ffado.org/wiki/IrqPriorities

take care for the IRQ stuff,
Be sure, a setting from 2 in the qjackctl settings tab "prio" result in a much lower prio then a setting from 80.

Code: Select all

HIGH PRIORITY – - – - – > – - – - – > – - – - – > – - – - – > – - – – LEAST PRIORITY
……..real time priority (static priority)…….| …. nice value (dynamic priority) …..
99 ……………….......…….. 50 ………..........……… 1 | -20 …….. -10 …….. 0 …….. 10 ……. 19