Can't adjust JACK2 latency (xruns)

[lapsio]

Hello

I'm trying to reduce xruns on my workstation (it's actually not music workstation, 3d workstation I use jack as DSP and patchbay not for music production). I found that you can reduce xruns by increasing latency and that can be achieved by increasing [Periods/Buffer] and [Frames/Period] in qjacktl. However even if I set some crazy value resulting in latency > 1000 ms displayed in qjackctl settings panel I still get 10ms. I'm using Asus Xonar D2 soundcard. Logs show that jackd is run with proper parameters. Here's full log:

Code: Select all

09:26:42.858 JACK is starting...
09:26:42.858 /usr/bin/jackd -v -P10 -dalsa -dhw:D2 -r192000 -p4096 -n8 -m -H -M
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
09:26:42.866 JACK was started with PID=11600.
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
Cannot create RT messagebuffer thread: Operation not permitted (1)
Retrying messagebuffer thread without RT scheduling
Messagebuffer not realtime; consider enabling RT scheduling for user
no message buffer overruns
`default' server already active
Failed to open server
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 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
09:26:42.885 JACK was stopped with exit status=255.
09:26:45.046 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
09:26:49.302 JACK connection change.
09:26:49.309 Client activated.
Cannot lock down 86605722 byte memory area (Cannot allocate memory)

... <and here lots of debug about new patchbay connections>

There's some mess with jack unable to startup it happens when I try to restart it too quckly but whatever, it works in general just some derps occur occasionally in log. So CLI parameters look okay yet when I play something I don't observe any latency at all. Also I'm not sure why it's not printed here now but I saw few times log saying that jack is using 8 periods but still latency was 10.3ms. Qjackctl shows something much above this value.

And xruns still occur when I launch anything more CPU intensive (and of course I do run because it's workstation). It's okay that sound glitches when I'm running some render on all 8 cores 100% let's be realistic, but it's quite disturbing when glitches occur also while I'm just recording screencasts with my work. Disturbing both for me and people watching screencasts as captured sound also glitches. It's not really something THAT computationally heavy, in worst case takes around 100-200% cpu so technically 6 cores are still free. I can minimize xruns by playing with chrt and CPU affinity to core-separate audio related apps and computationally heavy apps and make jack realtime however I'd rather prefer to increase latency. After all I don't have any reason to need latency below even 100ms. I'd be totally fine even with 200ms as long as it wouldn't glitch under higher load.

[English Guy]

Are you using an rt kernel?

[lapsio]

Is it required for increasing latency?

No i don't think I have. In fact I'm not even using desktop kernel I'm using full featured universal kernel as I'm using some workstation / server grade functionality so maybe it's compiled with realtime support - if having working RT schedulting means I have RT kernel then yes I do because it does work.

However till now my experience with realtime scheduling on jack wasn't especially nice - yesterday after few hours of usage jack with few other apps literally hanged and dmesg printed kernel error message that RT scheduler in kernel is stuck and effectively 4 cpu cores were dead (constant 100% load, inability to kill any process runing on them, every app starting on them freezed). I just managed to save my work, unmount some filesystems and hard reset. Luckily I set affinity of jack to only those 4 cores so I could still utilize remaining 4. I mean it happened only once, single failure but well quite unpleasant failure. If i was less careful I could loose something important.

[Pablo]

I suspect you (the user who starts jack) don't have rtprio and memlock privileges, regardless of the kernel.
What is the terminal output of
ulimit -r -l
?

Also, periods/buffer > 3 doesn't make sense. Use 2 or 3. Also, sampling rate 192000 is insane 48000 is the jack default and perfectly good.
I think the reason why different programs report different latency values is because they define latency in a different way,
and they usually put a calculated value, not a measured value. Use jack_iodelay to find about the real round-trip latency.

[tramp]

Maybe, if you didn't need capture channels you may run in playback only mode, without realtime permission.
try this, (85.3 ms) latency:

Code: Select all

/usr/bin/jackd  -t2000 -dalsa -r48000 -p4096 -n4  -Phw:D2

[gimmeapill]

As already mentioned, uncheck the "Real Time" check box in qjackctl. Your user doesn't have RT permissions, that why you cannot start jack on the first try. Then don't use more than 2 periods unless you sound card is connected by USB, in which case 3 might be better.
Setting properly RT permissions could nevertheless help with the xruns when your system gets heavily loaded (even at high latency).

That may be a stupid question, but wouldn't you be better off with Pulse Audio if you don't care about latency and just need a smooth audio output for screencasting?

[tramp]

Then don't use more than 2 periods unless you sound card is connected by USB, in which case 3 might be better.

For playback only, most cards support as well 4 frames, that will deliver you a additional buffer., more latency, more stable against X-runs.

Your user doesn't have RT permissions, that why you cannot start jack on the first try.

When I read it right, he could use rt-prio, but he didn't wont to that.

Setting properly RT permissions could nevertheless help with the xruns when your system gets heavily loaded (even at high latency).

Absolute, we didn't know which apps he use, but he said that he gets a deep freeze, so he wont give jack rt-prio, as it is a working machine.

That may be a stupid question, but wouldn't you be better off with Pulse Audio if you don't care about latency and just need a smooth audio output for screencasting?

Patch-bay, that is the point here I guess.
@lapsio do you do game development?

[lapsio]

Okay so as @tramp said I used this command:

Code: Select all

/usr/bin/jackd  -t2000 -dalsa -r48000 -p4096 -n4  -Phw:D2

then changed it to

Code: Select all

/usr/bin/jackd  -t2000 -dalsa -r96000 -p4096 -n4  -dhw:D2 -m -H -M

Because I use monitoring for screencasts. Input is not that important but nice to have, maybe just for line-in but tbh Xonar has pure hardware line-in passthrough so it'd be impossible to use JACK as DSP here anyways. I'm not sure how to achieve 1:1 the same in qjackctl so in the end it's launching:

Code: Select all

/usr/bin/jackd -v -r -dalsa -r96000 -p4096 -n4  -dhw:D2 -m -H -M

But it works really good comparing to what I had before. Almost no xruns (below 30 xruns in few minutes under excessive load, I used to have like 60 xruns per second) and without RT priority so I don't need to worry about stability. I didn't manage to use -r192k though because it introduces tons of xruns again. But even if it does limit max output sampling rate then I don't really even have any audio > 96k so 96k 24bit should be more than enough.

I don't know why increasing latency didn't do the job before. I think for some reason 192kHz doesn't work under high load no matter how high -n and -p are set.

Thanks guys

@gimmeapill I do use pulseaudio and did before. I use pulseaudio through JACK because I use JACK as system-wide DSP and patchbay and PA supports quite easy network transport so I can use this workstation as sound sink for all linux enabled devices in home plus basically absolutely every soft can use it. However it provides quite limited output management and sound processing, I think I already said that. So in the end pulseaudio catches all sound for JACK and then JACK actually does stuff with it.

To be more precise I installed JACK in the first place because I use Xonar which is 7.1 card as 3x stereo - headphones, speakers and sub, plus I typically don't use sub as it's just some Logitech Z2300 nowhere near to Behringer B3031A. JACK allows me to use 2 equalizers - one to imitate 60Hz low-pass filter for crappy sub and second for actual speakers. And then second one can be easily bypassed so in the end JACK allows me to easily switch between 2 audio "setups" - linear path (straight JACK, only monitos, no DSP for neutral, not annoying sound to listen for long hours during work) and "hifi" path (Jamin, monitos+sub, some equalizer and dynamics compression for "fun" sound). With just 1 or 2 clicks. Sometimes I like eqlized sound but it just tires me so I can't listen to it for more than few albums at most, whereas I have no problem with listening to flat response whole day.

Plus somehow I like using professional solutions for totally not professional use cases

@Pablo
192 khz @ 24 bit is native for my soundcard that's why I set 192 khz i thought it's reasonable in such circumstance. Does this value affect final ALSA sampling rate? Audio path should support something around 96 kHz sampling (48kHz real) with flac recorings, Xonar D2 and ribbon tweeters ~32kHz response range. I know we hear 20khz but I found plenty of articles describing why it actually does make sense to generate those frequencies because yada yada harmonics something. If it's not related to card sampling rate then It'd be valuable information for me.

@tramp - not only, I do provide some 3d and 2d game art for PonyKart dev team though (blender+UE4). I also do conventional graphics for Cycles renderer. Mostly static renders/meshes, no animations. And some webdev and general purpose programming a bit of everything so It's quite universal workstation... That's why I'm constantly running into troubles because stuff is colliding. It's really hard to make single machine for absolutely everything ever. Right now I have like 30 pages doc how to set up all this crap to work together under OpenSUSE because it's not that simple. But so far it surprisingly works somehow... I had many issues with graphics - multi headed setup on 2 GPUs (Quadro+GTX), 30bit color on Linux (10 bpc), server stuff - VirtualGL, xpra and VNC with multi user support to allow using PC as remote renderfarm or even remote workstation for other people when somebody needs it, audio especially ground loops everywhere and noises from motherboard but I've already fixed that, storage - I've run out of SATA ports for RAID ages ago and data integrity validation on few TB RAID array is meh, Security issues and access control, I don't want to limit any user (and access to GPU for CUDA is pretty high access already) but at the other hand I don't want anyone to hog 100% of machine (systemd slices help). Lots of trouble till now. I'm thinking of splitting this one workstation to 2 or 3 at least for quite a long time but well... It'd involve additional costs and integration issues. So I think I'll just try harder to eliminate collisions. I'll need to write some blog about this machine one day because it's freaking overkill...

[gimmeapill]

Not an easy config indeed. multi user render farm and audio are not exactly good neighbours

Looking at the last results, I think that 4 periods is still an overkill for a PCIe interface (unless you had maybe specific reasons to do it in the first place?). I'd rather go with 2 periods and a double buffer size - which gives at the end of the day the exact same latency:

Replace

Code: Select all

/usr/bin/jackd  -t2000 -dalsa -r96000 -p4096 -n4  -dhw:D2 -m -H -M

With

Code: Select all

/usr/bin/jackd  -t2000 -dalsa -r96000 -p8192 -n2  -dhw:D2 -m -H -M

And see how it goes (who knows, 7.1 might benefit from 4 buffers after all?)
As for the audible latency, I don't think you need to worry about it for screencasting as long as you stay <20-25 ms, so you should still have a comfy margin here.

Regarding CPU affinity: I've never managed to get good results with chrt or trying to outsmart the kernel scheduler, even with RT priorities tuning and IRQ threading. If you really want jack to sit on a single core, the easiest way would be to downgrade to jack1 - although this might not be possible with your distro or configuration (careful about the dependency hell). And of course, the main problem is that even by doing so, it may not help at all with xruns. For a complex configuration like yours I'd really not step in there, and rather try to isolate the other functions.

Another thought: since you have both pulse audio and Jack, did you ever try Cadence to manage the complex routing? It's heavier on dependencies but might as well make your life easier...