xruns

Hi
It seams my backend Alsa/Jack is running. But Ardour causes xruns in jack because it is too slow. msg:
JackEngine::XRun: client = ardour was not finished,
… and I get xruns when recording my guitar.
How can I give Ardour realtime status and allow it to grab all the memory it needs ?
I thought the PAM entry was for Jack only … or did I miss anything ?

Thanks in advance

The recording interface is a Behringer UMC404HD supporting samplerates from 44.1 khz to 192Khz.
I checked the installation of Jack and found on alsa-jack plugin missing and installed it. I still got xruns but none relating to Ardour or Musescore. The typical error (qjackctl msg window) is now

Jack: **** alsa_pcm: xrun of at least -96632012.800 msecs
10:15:25.354 XRUN callback (1).
Jack: ALSA XRun wait_status = 0
Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 12
Jack: JackRequest::Notification
Jack: JackEngine::ClientNotify: no callback for notification = 3
Jack: JackEngine::ClientNotify: no callback for notification = 3
Jack: JackExternalClient::ClientNotify ref = 2 client = qjackctl name = qjackctl notify = 3
Jack: JackExternalClient::ClientNotify ref = 3 client = ardour name = ardour notify = 3
Jack: JackClient::ClientNotify ref = 2 name = qjackctl notify = 3
Jack: JackClient::kXRunCallback

and

Jack: **** alsa_pcm: xrun of at least -96632209.408 msecs
Jack: ALSA XRun wait_status = 0
Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 12
Jack: JackRequest::Notification
Jack: JackEngine::ClientNotify: no callback for notification = 3
Jack: JackEngine::ClientNotify: no callback for notification = 3
Jack: JackExternalClient::ClientNotify ref = 2 client = qjackctl name = qjackctl notify = 3
Jack: JackExternalClient::ClientNotify ref = 3 client = ardour name = ardour notify = 3
Jack: JackClient::ClientNotify ref = 2 name = qjackctl notify = 3
Jack: JackClient::kXRunCallback
Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 13
Jack: JackSocketServerChannel::Execute : fPollTable i = 3 fd = 18
10:15:26.385 XRUN callback (1 skipped).

I installed all conceivible pug-ins for Alsa and Jack. I get less xruns maybe 1 per half an hour. Interesting to note is that I get xruns without an application (Ardour or Musescore). The problem appeared to be between Jack and Alsa ?!?

There is also the persistent rumor on the net that wifi causes xruns ???!? with the recommendation to disable wifi.

I also increased the “niceness” of Jackd and/or Ardour again still xruns.

It would be interesting to talk to a Jack developer.

Thanks and cheers

Which audio interface are you using? This has a significant bearing on what buffering setting may or may not work - as an example, some USB interfaces seem to require quite specific buffer / latency settings and some internal (on board) audio chipsets have problems if you have any of the inputs muted (even if you are not recording audio - with some drivers, muting unused inputs messes with the I/O buffer synchronization which then causes occasional xruns)

I wonder what "Jack: Process: graph not finished!" means
As I understand it, the 'Graph' refers to a dependency graph which JACK creates, to determine how all the client applications are related in the audio chain. The message implies that for whatever reason JACK didn't finish processing the entire graph in the available time, which, would lead to an xrun.

@anahata …: That’s what I would have thought too. But there is no change in priorities (or nice levels) in my process table. Also I would not want all my processes equaly raised in priority.

There seams to be sometimes a break in xruns . Anyway they are back but not in burst just single xrun about every 5 min. I single handedly increased the priorities of Jack processes and Ardour … no difference.
By the way I have the same problem with Musescore and Pulse Audio.
Here are 3 error reports. Maybe the solution is in there !!

Sun Jul 1 13:26:05 2018: Jack: JackSocketServerChannel::Execute : fPollTable i = 4 fd = 25
Sun Jul 1 13:26:05 2018: Jack: JackSocketServerChannel::Execute : fPollTable i = 5 fd = 28
13:26:12.685 XRUN callback (9).
Jack: JackClient::ClientNotify ref = 5 name = qjackctl notify = 3
Jack: JackClient::kXRunCallback
Sun Jul 1 13:26:12 2018: Jack: **** alsa_pcm: xrun of at least -21664026.624 msecs
Sun Jul 1 13:26:12 2018: Jack: ALSA XRun wait_status = 0
Sun Jul 1 13:26:12 2018: Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 14

Sun Jul 1 13:33:34 2018: Jack: Process: graph not finished!
Sun Jul 1 13:33:34 2018: Jack: Process: waiting to switch delta = 348377
Sun Jul 1 13:33:34 2018: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Sun Jul 1 13:33:34 2018: Jack: Process: graph not finished!
Sun Jul 1 13:33:34 2018: Jack: Process: waiting to switch delta = 360000
Su

Sun Jul 1 13:38:47 2018: Jack: JackSocketServerChannel::Execute : fPollTable i = 5 fd = 32
13:38:50.699 XRUN callback (10).
Jack: JackClient::ClientNotify ref = 5 name = qjackctl notify = 3
Jack: JackClient::kXRunCallback
Sun Jul 1 13:38:50 2018: Jack: **** alsa_pcm: xrun of at least -22422036.480 msecs
Sun Jul 1 13:38:50 2018: Jack: ALSA XRun wait_status = 0
Sun Jul 1 13:38:50 2018: Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 14
Sun Jul 1 13:38:50 2018: Jack: JackRequest::Notification

I wonder what “Jack: Process: graph not finished!” means

Thanks for your help and have a great Sunday

For an application to belong the the audio group, it has to be started by a user who belongs to that group. In general an application inherits all the user and group information of the user running it.

I am not sure if the issue can be solved at the Jack end.
The problem cannot be solved by jackd, either the Wi-Fi drivers must be changed to cooperate better, or possibly the RT patched kernel has developed a way to force the Wi-Fi drivers to allow pre-emption even while searching for networks. I don't know if there is an easily available RT kernel for SuSE you could try or not. I suppose it is only a problem if you need to use WiFi on that machine, if not needed you can just leave it disabled.

If this is a laptop you may have the wifi-card and your sound card on the same USB bus. If this is the case then this most likely can’t be fixed in software. If you have several USB busses on your computer (not many do), then you could try a different USB - port, but you probably already have done that.

Solved, at least according to recent tests.

I properly disabled the wifi network manager so that there is not search for wifi nodes respectively no wifi network processes running.
I let Ardour and Jack running in the evening with little load (a bit of recording) and then left it running over night for approx 12 hours. Result : zero xruns
The interference of wifi network processes in my case happens with openSuseLeap 15.0. According to internet search it happens with other Linux flavours too. I will let the openSuse Forum know about this problem since it affects all applications depending on Jack eg. Musescore or Hydrogen.
I am not sure if the issue can be solved at the Jack end.
It will remain an issue since users with xrun problems will first look at other remedies before by coincident hear about the wifi interference.

Thanks for your help !!!

Nice values have NOTHING to do with real time audio. It is unfortunate that there is so much incorrect information about this out there. “nice” values are a very, very specific thing on Unix-like operating systems, and are not relevant when processes are running with realtime scheduling priority. The “priority” values exposed by JACK are not “nice” values, but something entirely different.

There is very little point using a USB bus monitor to diagnose problems with xruns.

Many USB interfaces combined with common USB chipsets prefer to run at 48kHz; many of those prefer to run with 3 periods (buffers) rather than 2.

1 Like

@ccaudle … thank you for your detailed response. The qjackctl setting , when I changed to jackdbus were all the same
[Settings]
Audio=0
Chan=0
Dither=0
Driver=alsa
Frames=1024
HWMeter=false
HWMon=false
IgnoreHW=false
InChannels=0
InDevice=“hw:U192k,0”
InLatency=0
Interface=
MidiDriver=seq
Monitor=false
NoMemLock=false
OutChannels=0
OutDevice=“hw:U192k,0”
OutLatency=0
Periods=2
PortMax=256
Priority=50
Realtime=true
SampleRate=44100
Server=jackd
ServerName=
ServerSuffix=
Shorts=false
SoftMode=false
StartDelay=2
Timeout=500
UnlockMem=false
Verbose=true
Wait=21333
WordLength=16

all I changed where the frames per period and the niceness of the processes.

I used to run a M-audio 1010lt card. There is a difference.

I still have to find a usb bus monitoring tool see how the USB recording interface behaves. If you know some please let me know.

I looked into the wifi issue again and that I did not properly disabled it. So I did this time. As a result I was running an idle system Ardour and Jack for 3 hours with NO xruns. To be sure I will run it over night. So that’s good news. There is still the USB interface to be monitored and hopefully excluded

Anyway I will not hold my breath until further tests but it looks promising.

Thanks for you help

When I was using Ardour about 4 years ago I had no such issues.
Were you using the Behringer interface at that time? It seems there are a lot of reports in web forums of xruns with that device, even on windows.
Jack D-bus interface. So I tried and ...!!! that made a difference.
That probably indicates that you used different jackd settings when you launched jackd compared to the settings when using jackdbus. I do not see where you ever provided the settings you use. Have you tried running Ardour using the ALSA backend, so that Ardour controls all the settings (without jackd at all)?
there is no change in priorities (or nice levels) in my process table
What tool were you using to check priorities? The applications you are using have a combination of realtime and non-realtime threads, so you would probably have to use something like htop to display all the threads. If you use top I think that will only show the priority of the first thread started. I'm not positive about that, but I think that is the case. What argument did you use for -P to set realtime priority?
persistent rumor on the net that wifi causes xruns
Some wi-fi drivers monopolize the CPU core while attempting to scan for networks, or at least did in the past.

Are you running the default SuSE kernel, or the kernel-desktop variant kernel which is configured for slightly lower latency?

For problems like this which do not occur right away but only occur after some period of time it can be useful to notice whether the xruns occur at the same interval each time, e.g. do they occur exactly two hours apart, or every hour, etc.? The OS will be running periodic background tasks which should be set to run at low priority to not disrupt your work, but something like scanning for software updates, or indexing the files on your hard drive, could cause problems. Probably not very likely, something to keep in mind as you keep investigating.
You should also check the system messages file for any indication that the USB driver reported an error communicating with the device. If sometimes the audio device won’t respond when requested

Thanks for the URL. … put the thinking straight, sort of . Anyway I surfed the net and there was the talk that wifi and/or the actuall physical usb socket would make a difference. It did not. I also reduced the Frames / Period back to 1024 since it did not make any difference to the number of xruns.
What I also found on the net the people used D-Bus interface and Jack D-bus interface. So I tried and …!!! that made a difference. That may all change again but I am running Ardour/Jack for about 3 hours and NO xrun.
In general I don’t know if the entries in limits.conf made any difference. How would an application know that it belongs to a user group called "audio’ (in my case.)
I suspect that the D-Bus entries have an influence of the task sheduling. In that area I believe Ardour and Jack have been overlooked due to not high enough priority.
Thanks and I will keep you posted how I will go with this new jack setting.

You don’t have to give Ardour realtime status, it is Jack that’s complaining.

Make sure your limits.conf changes have taken effect by running the commands ulimit -r and ulimit -m in a terminal.
The first command should give you the realtime value of 99, if you have followed the Jack realtime scheduling page, and the other should say “unlimited”.
Also make sure you’ve started Jack with the realtime switch enabled.

If not you need to go back and make sure you’ve followed that page thoroughly.

Note that just because you’re running Jack in realtime doesn’t mean that you can go arbitrarily low on the frames/period and periods/buffer settings. That depends to some extent on what your hardware can cope with.
Try increasing the frames/period to 1024 and see if that works. If it does you lower it until you get xruns and then you increase it to the next, higher level.

I went through all the steps again (as suggested) and it works , no xrun. That’s good, but I wonder what I missed.

Anyway, thanks

People sometimes forget to log out and in again after having changed the limits.conf file.
Maybe that’s why it worked the second time.

@peder. to your comment, I did logout and login. I must have missed something else. Anyway the joy was only short lived I got xruns again. xruns as shown in the qjackctl message window. The funny thing is, that I get
JackEngine::XRun: client = ardour was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
!!! when Ardour is idle. I don’t record nor do anything else.
By the way the only application running are Ardour and Jack. So one should assume a smooth running of Ardour and Jack ?!?
I will try to trace the issues and post the results.
When I was using Ardour about 4 years ago I had no such issues.
Anyway , thanks for looking into this
Cheers

What are your frames/period and periods/buffer settings?
Are you using Ardour 5.12 or some older version?
Did you try increasing frames/period to 1024, or even 2048, to see if that works?

You only need a small number of f/p if you’re using softsynths or playing through Guitarix, not if you’re only recording external audio and mixing.

If the xruns occur when Ardour is idle, could it be that your system is set for ondemand or powersave clock management, and the processor clocks are being changed to a lower frequency at that time? Find the processor power controls for your distribution and change to performance if it is currently set to powersave or ondemand and see if that eliminates the xruns.

I am using Ardour 5.12 , Jack2 and run openSuseLeap15.0 . I know that Suse is CPU frequency scaling, since I run Ardour 3.5 or 4 (?) some time ago on Suse without xrun problems that might not be the issue ???
The current xruns occur at Jack but causes crackling in the sound system it might also interfere with recording.
Ardour does not use a lot of CPU power , about 2%. However Ardour uses Memory 277000k and shared memory 150000k.
That is with 3 very small miditracks and a very small Audio track.
I increased in qjackctl Frames/Period to 2048 (what does that actually mean ?)
For todays session the first 2 hours no xrun. That was with recording from musescore to Ardour. on problem. Then 2nd half of the session plenty of xrun in jack.
I will try if I can manipulate the CPU clock… see what happens. What strikes me is the high amount of memory Ardour is using.
Any further ideas ? Thanks

Hi!
“Frames/Period to 2048 (what does that actually mean ?)”

A good video (about buffer size there’s a nice diagram from 8:15):