Ardour reporting xruns but cadence doesn't

Ardour 6.9-4 running on Manjaro XFCE (4.16) with Cadence 0.9.1-5.
Jack is configured to 48k with buffer size 256 and 2 periods / buffer. I’m using a Focusrite Scarlett 2i4 2nd generation as USB interface.

Starting Jack from Cadence is OK, and having it run idle in the background produces no xruns - typical DSP load <= 5 % (while browsing and other tasks). Starting Ardour increases DSP load to <= 11 % without xruns. But doing something, like adding a track, makes Ardour report xruns (in the titlebar, after the DSP percentage) . Sometimes just a few (like today, 4), at other times more, like 20-30. All the time while Cadence reports zero.

Anyone have an idea whats going on here?

I don’t know why Cadence isn’t reporting anything but as for Ardour and xruns, you should try using 3 periods/buffer.
Many USB interfaces work better with that setting (and note that -p3 should be -n3, as corrected in a subsequent post) :

Thanks for answering! I’ve been playing around with settings according to the table in your link and Ardour keeps reporting xruns when adding or removing one audio mono track. Last try was sample rate 48 k, buffer size 1024 and periods/buffer 3.

Cadence keep consistently reporting zero. The only (expected) difference I notice is that DSP load is reduced each time buffer size increases.

So while I can heed your advice and switch to 3 buffers instead of 2 I still don’t see why Ardour reports xruns and Cadence doesn’t. Are they not getting info from the same place?

Anyway, a few days ago, after adding a track and getting xrun reports in Ardour, I could record and play back for a long time (48k, 256/2) without any further xruns reported anywhere.

Ardour has to reorder the audio connection graph when adding (or removing) tracks, I would not be concerned with xruns when adding tracks. Don’t add or remove tracks while in the middle of recording other parts and it should be no problem.

You did not mention which version of jackd ships with Manjaro. JACK v1 (i.e. jackd 0.125) disrupts processing when adding or removing connections, JACK v2 (i.e. jackd 1.9.xx) should not disrupt processing when adding connections. I don’t know if Ardour may still stop processing internally for a period when changing connections, but that may explain why Ardour displays an xrun but the external jackd monitor does not.

Thanks Chris! You’re right that I shouldn’t worry about xruns when adding / removing tracks (which I would NEVER do while recording anyway).

I’m just puzzled Ardour is reporting xruns and Cadence not. I will investigate your idea that the internal processing stops and creates “internal” xruns. If there are none while recording I’ll be happy!

As for jack, I made sure jack2 is installed. Currently I have version 1.9.20-4 from the official Manjaro repositories.

That may well, be. Adding tracks (and changing connections) is not realtime safe.

It may be that Ardour is about to add a new track, while JACK would want to run Ardour. In that case Ardour does nothing (just returns), but increments the over/under-run counter. Since Ardour just returns, JACK won’t see an x-run. Other JACK apps are not affected.

Yep Ardour frequently reports xruns when adding tracks and suchlike, as @ccaudle mentioned. It would only be a problem during recording or export. This thread, along with personal experience, has made me feel much more relaxed about it. :slight_smile:

Thanks Chris and Robin!

I’m marking this as solved… Except it seems I can’t edit the original post anymore :thinking:

I get one xrun predictively everytime when I close a session and jack also sees it. That happens now after upgrading from Ardour 5 to Ardour 6.5 a few days ago. In Ardour 5 there where never xruns on closing or recording for hours.

I have to test a little more to see if recording is affected by the upgrade, to be sure about that.

Is it also considered “not realtime safe” when closing tge session and jack reporting the xrun, too? If not I will open a new thread for that.

x-runs are only problematic if they occur while you are actually using the audio system: in particular, while recording (because they represent lost audio data that cannot be recovered). If I only ever saw x-runs while closing an Ardour session, I would count myself extremely lucky.

Thanks for your feedback.
I try to get it done once and for all so ideally I want no xruns whatever I do. That worked for nearly two years now. See Is it really possible to get down to 0 Xruns? - #82 by topas and before posts for details on my way to 0 xruns.
So it seems possible.
If there are xruns that I cannot get rid of (not realtime safe) I would change my mind and accept that, too.

I saw that some user actions were discussed and were evaulated as not realtime safe and since I have this issue of xruns when closing the session I also eanted to ask if this falls under this user action topic, too.

The strange thing is that the xruns I have now are related to just updating Ardour. And they are not only when closing the session. After upgrading I see them also when recording and only when Ardour runs. A guitar ampsim does not report xruns as before for hours.

Xruns after upgrading while recording is a different topic and I’ll create a new thread for that. Here I just wanted to ask for the session closing.