Upgrading Ardour 5 to Ardour 6 on Debian introduces xruns

Hello everyone,

I have upgraded my Ardour 5.12 on Debian and I get xruns while using Ardour 6.5 which was not the case before the upgrade. I cannot find a good explanation for this on my own, so I would like to get sone other opinions on that problem.

The details on my setup and stuff were intensively posted around comment Is it really possible to get down to 0 Xruns? - #82 by topas.

Basically I had to

  • disable WIFI
  • use Liquorix low latency kernel (or in other words: use a 1000Hz kernel, because with liquorix version not using 1000Hz setting I got xruns)
  • use realtime execution rights for the user to run jack in RT

to make 48000 Hz / 128 buffer size / 2 periods and pulseaudio bridged to jack work without xruns for hours used at least once a week for about two years now. That even worked after switching from Debian Buster to Debian Bullseye by using a fresh install of the distro and setting it all up again.

The Ardour version was from kxstudio repo and I realised that this version is not managed anymore and even my Debian stable version is newer. So I upgraded to that. I did not changed any other setting.

Once that was done I experienced xruns when

  • closing the Ardour session (EVERY time I close it I get exactly one xrun - that may be related to non realtime safe software parts of Ardour - so lets not fix this, but remember it)
  • When I test my setup by letting it run for at least six hours I get xruns WHEN ARDOUR IS RUNNING IN THE SETUP (no xruns for at least 6 hours when I just remove Ardour from the setup (tested twice)

The second point is what bothers me.

Test setup briefly: Running Ardour and Guitarix while Ardour is loop recording the output of Guitarix and another input channel. (Pulseaudio bridged and RAW MIDI driver and MIDI bridge running)

To verify this I took another notebook I found and did the same. Setup my definition for setup for 0 xruns and tested it in the same way as on my main PC with Ardour 5 and then with Ardour 6. The results are the same for the xruns when closing the session. I did not let this thing run for longer to see xruns while recording. I can do that if necessary.
So the same behavior on another computer.

Usually the discussions about xruns start by examine the PC setup. I can’t believe I can solve this using my PC setup because the people in other discussions have xruns if Ardour runs or not and this was the case for me, too before tweaking the things I have done. Xruns after a few hours even when no jack app was started - just running jack created xruns. Since I don’t have this and did not have this before the upgrade I think it is Ardour related - but I don’t know - I am not an Ardour expert, but a programmer.

Thats why I thought maybe the callbacks from jack into Ardour might need more processing power and changed my CPU (i5 3570k 4 cores at about 3.4 GHz) to maximum clock rate - withoit success.

What do you think about this?

The xruns that occur during the tests (long run test, not closing the session) are NOT shown in jack logs. Claudia (kxstudio) shows the xrun count, but in the Claudia logs of jack the are not reported.

Does it matter if jack does not show them? When closing the session there is also ine xrun and they are shown in the jack log.

Additionally the xruns are shown as markers in the timeline in Ardour they are green. In the previous Version it was yellow. I assume this is a change in behavior between versions and there are no green AND yellow markers showing different severities of xruns.

Is this correct?

Tested that with a demo of version 6.9 which was installed through the installer, too. That makes sure it is not a package error in Debian or a specific issue in Version 6.5.

Do you use any plugins?

In Ardour 6.9, check:

  • Ardour Menu > Winodw > Plugin DSP Load
  • Ardour Menu > Window > Performance meters

Also for low latency, enable Preferences > Performance > Power Management, CPU DMA Latency (this may require ardour/99-cpu-dma-latency.rules at master · Ardour/ardour · GitHub to be saved to /etc/udev/rules.d/).

This changed in 6.8/6.9. Previously x-run markers were shown in the ruler on the timeline, using absolute time.
Now the markers are part of the audio source region (shown as triangles). So if a region is moved or reused, it is still visible where the underrun during recording occurred in the corresponding source file.

Not in the test.
When I record the guitar and another mic I use Guitarix as an insert in one channel to record clean.

Thanks for your help. :slight_smile:

Since the xruns of my recent tests were not logged in jack I wanted to find out if xruns are never logged in jack. To provoke xruns in jack I reduced the buffer size from 128 to 64/32 and at the end 16 because above not many xruns ocurred.
These xruns are logged in jack (together with the configuration changes):

Wed Mar 23 20:16:51 2022: configuring for 48000Hz, period = 64 frames (1.3 ms), buffer = 2 periods
Wed Mar 23 20:16:51 2022: ALSA: final selected sample format for capture: 32bit integer little-endian
Wed Mar 23 20:16:51 2022: ALSA: use 2 periods for capture
Wed Mar 23 20:16:51 2022: ALSA: final selected sample format for playback: 32bit integer little-endian
Wed Mar 23 20:16:51 2022: ALSA: use 2 periods for playback
Wed Mar 23 20:17:16 2022: configuring for 48000Hz, period = 32 frames (0.7 ms), buffer = 2 periods
Wed Mar 23 20:17:16 2022: ALSA: final selected sample format for capture: 32bit integer little-endian
Wed Mar 23 20:17:16 2022: ALSA: use 2 periods for capture
Wed Mar 23 20:17:16 2022: ALSA: final selected sample format for playback: 32bit integer little-endian
Wed Mar 23 20:17:16 2022: ALSA: use 2 periods for playback
Wed Mar 23 20:18:05 2022: New client 'a2j' with PID 7597
Wed Mar 23 20:18:51 2022: configuring for 48000Hz, period = 16 frames (0.3 ms), buffer = 2 periods
Wed Mar 23 20:18:51 2022: ALSA: final selected sample format for capture: 32bit integer little-endian
Wed Mar 23 20:18:51 2022: ALSA: use 2 periods for capture
Wed Mar 23 20:18:51 2022: ALSA: final selected sample format for playback: 32bit integer little-endian
Wed Mar 23 20:18:51 2022: ALSA: use 2 periods for playback
Wed Mar 23 20:18:53 2022: ERROR: JackEngine::XRun: client ardour finished after current callback
Wed Mar 23 20:18:53 2022: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wed Mar 23 20:18:53 2022: ERROR: JackEngine::XRun: client = ardour was not finished, state = Running
Wed Mar 23 20:18:53 2022: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wed Mar 23 20:18:54 2022: ERROR: JackEngine::XRun: client = ardour was not finished, state = Running
Wed Mar 23 20:18:54 2022: ERROR: JackAudioDriver::ProcessGraphAsyncMaster: Process error

So generally if there are xruns in jack they are logged.

Additionally I tested the Ardour 6.9 demo over a long period, to see if it also has these sporadic xruns while recording as 6.5 has and if these are also not reported by jack.

I also kept the performance meters on during this test.

The results are

  • xruns in Ardour kept coming (8 in about 8 hours)
  • jack reported no xrun
  • Claudia showed the same xrun count that Ardour shows
  • One xrun marker has a different colour in Ardour than the other xrun markers and there is a message about a weird latency that very likely belongs to that xrun in the Ardour log.
  • The Ardour log does not show anytging about xruns

Here is the Ardour log:

2022-03-23T20:26:49 [INFO]: harvid version: 803
2022-03-23T20:26:50 [INFO]: Loading menus from /opt/Ardour-6.9.0/etc/ardour.menus
2022-03-23T20:26:50 [INFO]: Loading user ui scripts file /home/tobiasb/.config/ardour6/ui_scripts
2022-03-23T20:26:50 [INFO]: Loading plugin order file /home/tobiasb/.config/ardour6/plugin_metadata/plugin_order
2022-03-23T20:26:51 [INFO]: Loading history from /home/tobiasb/DATA/Audio/Linux low latency/Ardour six hours plus test/Ardour six hours plus test.history
2022-03-23T20:26:51 [INFO]: Ardour six hours plus test: no history file "/home/tobiasb/DATA/Audio/Linux low latency/Ardour six hours plus test/Ardour six hours plus test.history" for this session.
2022-03-23T20:32:03 [WARNING]: Ambiguous latency for port 'insert 1/audio_send 1' (16, 288)
2022-03-23T20:35:56 [WARNING]: Ambiguous latency for port 'insert 1/audio_send 1' (16, 304)
2022-03-23T20:36:01 [WARNING]: Ambiguous latency for port 'insert 1/audio_send 1' (16, 304)
2022-03-23T20:36:05 [WARNING]: Ambiguous latency for port 'insert 1/audio_send 1' (16, 304)
2022-03-23T22:13:13 [WARNING]: Could not set CPU DMA latency to 0 usec (Permission denied)
2022-03-23T22:13:18 [WARNING]: Could not set CPU DMA latency to 1 usec (Permission denied)

Here us the performance meter data:
Performance meters

What can be read from it? EVrything ok, or are there problems?

This is interesting and caused by permission problems (tested without ‘99-cpu-dma-latency.rules’ file because I had no time) I was unable to experiment with it. I’ll test that soon.
By the way: which setting should I use? Lowest latency or a specific value?

A very interesting test would also be to provoke xruns in Ardour and see if other programs connected ro jack report xruns, because jack does not report them.
I don’t know which program is good fir it. Maybe Guitarix. Don’t know if it logs xruns somewhere.

It means that worst case Ardour causes 20.62% DSP load and is not the (direct) source of the xruns. In each cycle, there are still 2.1 ms available for other JACK applications and JACK itself.

The default is the lowest value that is not zero (here 2 usec).

If you pick 0, the CPU will never enter low power states which may cause issues if the system is not sufficiently cooled. This may trigger thermal throttling of the CPU.

see also

I had some time to investigate.

I did not use the Ardour settings for enabling CPU_DMA_LATENCY because I think it it a nice concept and it should be available without using Ardour. I found the ‘tuned-adm’ tools and enabled the latency profile which does at least the same thing than the Ardour power management does:

the profile requests a cpu_dma_latency value of 1

See (2.5.2. Tuned-adm Red Hat Enterprise Linux 6 | Red Hat Customer Portal) for details

It does lower the DSP load, but does not prevent the xruns.

What can be the reason for these xruns to appear after upgrading?

Does someone has an explanation for that so that the problem cause is know before proposing solutions?

The only explanation that I have is that the new Ardour adds more load to the buffer calculation, because it just does more and the peaks of latency that the machine has are coming through now (calculation of Ardour buffer takes longer and the calculation of all the buffers for all programs take longer that 2.7 ms (128 samples)). Since I use Pulseaudio bridged to jack I first stopped that bridge for a test to leave more room (time) for the buffer calculation of the other programs (Ardour) used in jack. That did not help. (while leaving out Ardour works)

I think I’ll make a test with just Ardour running, so I leave even Guitarix out. That would leave more time for Ardours buffer calculation.

Something else that is interesting is that reverting the actions that caused the problem, like downgrading Ardour 6.5 (Debian repos) to 5.12 (kxstudio repos - old and unmaintained) does not revert the problem. So there is no way back.

Why?

A screenshot I took while testing this issue with a fresh Debian installation (created a backup image of the original installation) shows that with the Ardour installation from the Debian repos after uninstalling the kxstudio version some packages other than Ardour were upgraded, too.

I think I’ll try to find out if they are the cause for this.
They could only be the reason if they would not be included in the performance meters of Ardour cause they show that Ardour alone is not the cause for the xruns.

I could install the Ardour 6.9 demo from the installer in a fresh Debian installation without installing Ardour from the Debian repos before. That would leave these packages in its unupdated state.

It is very likely that the upgrade of these libs is the cause for xruns increase. I did

No xruns appeared for more than seven hours.

(The only thing that made me nervous was the silenced output message of the Ardour demo which I forgot to accept few minutes after the beginning of the test. It just stood there while the test was running. I hope that not accepting the message is like clicking ‘remain silent’ and it does not affect the test. It seems unlikely because the loop region was overwritten about 700 times. Seems like it recorded normally)

I think I’ll repeat the test once more. When it shoes the same result I’ll downgrade the libraries and use Ardour 6.5 from the Debian repo. After that I have to identify which library the cause is and file an issue at Debian.

I’ll let you know when the second test has been made. The rest is not interesting for this Forum I think. (Maybe I link the Debian issue.

When people complain about Ardour providing their own paid bundles they should consider this scenario as being one of the benefits you’re getting (besides tech support)… How many hours have you been chasing this around? Would giving a few bucks (even one buck at the minimum) to the project and getting a bundle with it’s own tested, tweaked, patched and predictable support libraries really be so bad?

You’re really going back to Ardour 6.5 and spending several more hours downgrading support libs (good luck with that BTW) and chasing a problem that a bundle completely alleviates?

Those libs get upgraded because the Debian package apparently includes the audio/video editing side as well; with ardour-video-timeline, harvid and xjadeo.

It’s possible that the xruns will disappear if you uninstall ardour-video-timeline, harvid and xjadeo but it could also be that the Debian version of ardour is buggy.

A donation is a good idea, thanks for the reminder. I checked my donations and found that I did not donate to Ardour yet.

Thanks for the hint.
I think this cannot be the reason. After I found this problem I purged the Ardour 6.5 package using apt and ran autoremove and autoclean. That should have removed everything that CAN be removed when Ardour 6.5 package is uninstalled. (Including I’ll check if thats true)

After that I installed Ardour 6.9 demo using the installer and the issue was still present.
I also installed Ardour in version 5.12 from the kxstudio repo again. This version then also has the same problem.

Since the 6.9 demo works in a pristine Debian install the problems appear to arise from something that gets added or changed when you install the Debian version of ardour.
And which doesn’t get cleanly reverted when you purge ardour; like it probably didn’t remove ffmpeg, mplayer and mencoder and downgrade the libav/libsw-libs, for instance.

Yep. There are some libs updated on a vanilla Debian as shown in the screenshot in one of my previous posts:

I guess they are the cause. The updates they received were security updates from October 2021.
Have to talk to Debian team to find out how to proceed. I have no idea how to proceed with the situation.

I think for now we don’t need to investigate further in this thread.
Thabks all for your help.

This is my first try to diagnose massive xruns with Ardour 6.6 on Debian 11. If you find a solution, could you come back here and update this thread? I won’t extend the thread but it seems like you’re pursuing a line of inquiry that might address my problem too.

Ardour does not use ffmpeg/libavocode directly.

Ardour can launch ffmpeg (the commandline tool) to import/export video, or export mp3, but this is entirely separate, Ardour is not linked against those libraries to avoid codec patent/licensing issues.

1 Like

Sure, I was a bit busy with other things.

I was unable to get my system to work without xruns, even when downgrading the libraries and any package that was installed by installing Ardour 6.5 from the package manager (Things like libaubio and so on). So that seems to be not the cause for it.

Also using an Ardour provided bundle (demo version) did not help me after Ardour was installed through the package once.

Getting back to your comment: Just using an Ardour bundle does not help me currently.

So what could it be if it is not something that was installed when installing Ardour? Maybe something that was installed or changed long ago or was this present all time but it didn’t show up. How to find out?

I recovered a backup image of my system from December 2021. Ardour 6.5 was never installed in this image.
I want to find out if the system is stable (in low latency terms and with the methods that I do test it with) at all first. I do not test this every day and there are Debian updates coming in and I assume they do not cause the system to xrun (when using Ardour). But they could possibly do.
So, after going back by reverting to an image from December I will first intensively test the present system (Test it with my test setup for at least six hours and about five times in a row) to be more sure that this thing is as stable as I think it is.

When I am confident that there are no problems I will try to use a bundled version.
If that works I have at least a working and up to date version of Ardour.

I might then try to make Debian better and contact the maintainers of the Ardour package and try to find out if there is an issue in the packages.

What is your story with that? Did you just update? Do you use a bundle or a Debian package? Did it work before? What was the setup before?

my puzzler is a bit different than yours, which is why i was reluctant to include it. here’s a really-short version, still trying to keep this thread focused on your situation.

environment: headless Linode installation of Debian 11, Ardour 6.6 (installed with a script, using ‘apt’ that’s what gets loaded). 18 participants are joining a session using Jacktrip (1.5.1). that session is being mixed in Ardour. 18 input channels (everybody’s uploading in mono) upmixed to stereo before they hit the DAW, a few stereo hops across the DAW and the 36 output channels back to players (listening in stereo). so far, everything is solid/clean, no xruns.

xruns arrive when i attempt to multi-channel record all 18 tracks. then we get lots of xruns and players hear gremlins - little robotic-sounding grumblings in the background. i’m developing a list of possible causes for our next session:

  • phase-errors in the upmixing (connecting a single incoming Jack channel into the stereo input-channels in Ardour)
  • incorrect CPU-preference setting (right now Ardour claims all but one CPU core, out of 16 – perhaps assigning a few more cores to non-DSP processes will leave more room for the record-writes to run)
  • incorrect bit-depth setting (currently writing 16-bit audio – maybe going to 32-bit will eliminate the need for the write-process to resample the audio before writing the file)
  • incorrect denormals setting (not sure what this will do, but I’m keen to play around with it)
  • inadequate disk buffering (i have lots of memory to spare so I’ll crank it to 11 and see what happens)
  • inadequate waveform cache (same here)

see what i mean? i’m just a newbie learning the ropes. i want to hear about your solution, but i don’t want to hijack the thread. if folks have tips, let’s either start a new thread or you can PM me.