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.
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 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.
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.
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.
I fixed the xrun issue and want to report as requested by @OConnorStP.
I fixed the issue by accident. Wanted to just try a realtime kernel because I stumbled across this.
I built a kernel from source, because I did not find an RT kernel with 1000Hz timer settings.
I took a config from Debian RT kernel package and patched the kernel source with realtime patches and configured it with 1000 Hz timer settings.
I was unable to test it because I had nVidia drivers running whivh don’t work with RT. I did not want to uninstall them and I was unable to get around this by adding kernel blacklisting parameters to grub config, so I just changed to my internal GPU that uses nouveau driver for the test of the RT 1000Hz kernel.
I tested that setup with Ardour 6.5 from Debian repos recording a loop section of two channels together with Guitarix running and MIDI raw driver active, MIDI bridge and Pulseaudio bridge running for at least six hours (six to eight typically) for four times. So I am a little more sure that this setup is stable before posting back here.
I don’t know if this is helpful for you.
I want to find out which of the things that I did really removes the xruns:
RT kernel? (Had 1000Hz setting already before so it is just the kernel, or config difference against liquorix)
GPU change? (Cannot really be, the GPU before worked perfectly
GPU driver change? (Might be, I found some reports that indicate they do not ibfluence system latency and some said they do)
The RT kernel could have been it, but like Paul said the 1000Hz setting seems to be irrelevant today, so using the RT kernel packaged by Debian should suffice if you find yourself doing a new install in the future. Did you also install the rtirq program to prioritize your soundcard? If not, that is recommended.
I had a desktop years ago with a NVIDIA card. It constantly spewed xruns until I installed the proprietary driver and then went into NVIDIA’s settings panel and checked a box for “Performance” or something similar. After doing that, it behaved normally, so the GPU changes could have been it. I could only use a low-latency kernel with it, not a RT kernel, but it was adequate. I believe the Liquorix kernel plays nice with NVIDIA drivers, too, if you want to try it.
After that computer was retired, I have only bought computers with Intel HD graphics built-in because I don’t need a dedicated GPU, and it removes a layer of complexity to audio setup, assuming the situation today isn’t too different than it was several years ago.
A test with Liquorix and the onboard graphics card that uses nouveau driver shows xruns again (with the RT kernel there were no xruns). So nVidia drivers cannot be the problem here.
As soon as I find a way to quickly change to nouveau (blacklisting nVidia ideally, no uninstall) I’ll test if the RT kernel will work with the nVidia GPU and the nouveau driver to show that only changing the kernel to RT makes the difference, not the change of GPU or driver. But when I think about it - it is very unlikely that liquorix performs better with a dedicated nVidia GPU compared to the onboard GPU.
So I looks like currently in Debian I need an RT kernel which was not necessary before.
Lets find out right? I already tested the RT kernel from the Debian repositories two years ago they did not do the job. I report back how it performs.
No, I didn’t. Yeah maybe thats better, but it seems enough to have RT, 1kHz and WIFI off. There are so many other things that are suggested to make it better, but when there are no xruns with the current measures, why changing something?
I tried some of them some time ago, see some comments in Is it really possible to get down to 0 Xruns
Good to know!
I used the nVidia drivers together with liquorix and even tested it once for 6+ hours and I thought it works. Today it doesn’t anymore and I am not sure why. For now I just know that an RT kernel performs better.
I tried the official Debian RT kernel and it produces xruns. This kernel does not have the 1000Hz setting. It also not the best test, since I should have used my own build and adopt it but it consumes so much rime to build. Maybe later.
For building my RT kernel with 1000Hz I took the config of the stock RT kernel and changed the timers. So there should be only the timer settings that are different between stock and the kernel that has no xruns.
God bless you Robin. I’ve been dealing with shit DSP for months. I built a new computer much more powerful that my last and used the opportunity to upgrade to Mixbus7 and for months I’ve been trying to figure out with my DSP is worse than on my old comp. This one line of code fixed everything.
