Upgrading Ardour 5 to Ardour 6 on Debian introduces xruns

Installation & Configuration Linux
#2

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?

#3

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.

#4

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.

1 Like
#5

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

#6

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.

#7

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

#8

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.

#9

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.

Ardour 5 to 6 upgrade packages
Ardour 5 to 6 upgrade packages1080×678 290 KB

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.

#10

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.

#11

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?

#12

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.

#13

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

#14

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.

#15

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.

#16

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.

#17

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.

#18

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
#19

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?

#20

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.

#21

There are many variables playing together. I would isolate things a bit, like testing it with one or two users or the single machines before going into network connections.

I think this thread is quite done since it is not an Ardour upgrading issue.

These tests showed that there are xruns even before upgrading to Ardour 6.5 using the Debian repos. (Though they are rare)

That means I can test further on my own. Since I know it worked better two years ago I could go back and test a vanilla Debian installation more intense. If there are issues it could be an issue caused by a changed hardware. If not it could be updates.

I try to post back here, when I find the cause for it.

Good luck for your setup. Maybe you open a separate thread for it.