Ardour seems to conflict with other sounds in the system

Hi,

When I’m working on a relatively big project, let’s say around 50 tracks with a certain amount of heavy plugins (a lot of reverbs for example) and there is a sound produced by the system (be it a notification, or maybe a warning sound, when I’m pressing the backspace button in the plugin search, when the field is empty), Ardour is freezing and stops playing any sound for some time, and the system sound also can’t really play properly. With the project I’m currently working on, Ardour is happening not to respond for a bit in such cases.

I’m on Linux with Pipewire, and I was blaming it, as it’s often mentioned here, that one shouldn’t use Ardour with Pipewire. But I’ve decided to test, how it goes with other DAWs, and surprisingly for me, it’s not happening there at all, I’ve tested Reaper and Bitwig, both are using JACK and the same buffer size.

Here go dummy sessions with a lot of reverbs each, that I’ve created to show what I mean. There is a lot of xruns, they are not coming from DAWs, they seem to be coming from OBS Studio.

Please be careful, they might sound quite disturbing, but hopefully not too loud
Ardour: https://s3.badhouseplants.net/public-download/ArdourIssue/Ardour.webm
Bitwig: https://s3.badhouseplants.net/public-download/ArdourIssue/Bitwig.webm
Reaper: https://s3.badhouseplants.net/public-download/ArdourIssue/Reaper.webm

I’m pretty sure that I haven’t configured something in Ardour properly, and it’s causing the issue, but I can’t understand what it can be, so any help would be appreciated.

Thanks

as it’s often mentioned here, that one shouldn’t use Ardour with Pipewire.

I don’t know where you’re reading this, but it is absolutely incorrect. Depending on the distro there can be specific issues with the pipewire configuration, but Ardour works fine with pipewire using the JACK/Pipewire backend. You do need pipewire version 1.2 at least, and preferably newer than that.

1 Like

The first thing you should do is to use the ALSA backend to check how that works. If the problem still occurs, then it’s not a pipewire issue and we can dive a little deeper …

1 Like

I don’t know where you’re reading this, but it is absolutely incorrect.

I probably didn’t put it right. I see it’s often mentioned, then Alsa seems to be a preferable backend. I’m on fedora 42, and I have pipewire 1.4.7

The first thing you should do is to use the ALSA backend to check how that works. If the problem still occurs, then it’s not a pipewire issue and we can dive a little deeper …

I might be missing something, but I’m not sure how to test it with Alsa, as with alsa Ardour is taking kinda exclusive control of the audio device, and the system has to use another one. I’m not sure how to say it right, but for example, when I point Ardour to a Focusrite audio card with Alsa, it’s becoming unavailable for the system, and hence system is using the built-in speakers.

In such a setup, I don’t have any issues with the sounds, but also I take it as I don’t have any sounds apart from the Ardour ones. So I’m not sure how relevant it is.

If the problem still occurs, then it’s not a pipewire issue

I mean, I won’t be surprised it it’s a pipewire issue. But I can’t understand why in Reaper and Bitwig it just works, if I use the same backend. It made me think that I might have something misconfigured in Ardour

Do you use the JACK backend in Reaper? Bitwig actually uses Pipewire’s “own” API, which I think should never have existed …

The reason the ALSA backend is “preferred” for diagnostic purposes is that there is essentially zero configuration involved. Pipewire has lots and lots of configuration possibilities, and is also still evolving, which makes it tricky to easily diagnose where problems could be. Nevertheless, it’s what I use all day long.

Do you use the JACK backend in Reaper? Bitwig actually uses Pipewire’s “own” API, which I think should never have existed

I’m using JACK in Reaper, and I also use JACK, not Pipewire in Bitwig,

can you test this with the ALSA backend and see what happens? I am not aware that any sound should be produced under these conditions (by the kbd interaction). I certainly don’t hear anything when doing this with 8.12 using JACK/Pipewire.

also, i assume that this is ardour from ardour.org?

can you test this with the ALSA backend and see what happens? I am not aware that any sound should be produced under these conditions (by the kbd interaction). I certainly don’t hear anything when doing this with 8.12 using JACK/Pipewire.

I’ve tested with Alsa, and the sound is just coming out of the speakers chosen by the system.
It’s also not popping up when the notifications are turned off.

When using Pipewire, that’s what I got

It might be a bit louder than expected.
Sound Example: https://s3.badhouseplants.net/public-download/ArdourIssue/EmptyPluginSearch.webm

also, i assume that this is ardour from ardour.org?

The video is recorded with the flatpak version, because I wanted to have the same environment for all the DAW I’m testing, but the same thing is happening with the version coming from the Fedora repos, and with the one from ardour.org

This seems either impossible or the result of some system level configuration. Ardour here makes no sound whatsoever using a “system beep” to indicate kbd input conditions like “nothing to delete” …

Isn’t that dependent on how you have the desktop environment configured? Or is Ardour not using a standard input driver such that it can override DE configured behavior?

I actually don’t know. GTK does have functions that make beeping noises, or attempt to, but I’ve never heard them from any app I use, including Ardour. Yes, it would involve the DE

To be honest, i think Ardour is the only app I hear it from

Thing is, I can’t check how Ardour behaves here because nothing here generates audible notifications.

I just remembered that I have a little script called say which uses espeak for text-to-speech.

I had ardour running (not a large session), and got say to … well, say a bunch of stuff. Ardour’s output was unaffected. This is all via pipewire.

HOWEVER … I loaded a larger session and ran say in a loop in the background. Behavior replicated.

I then tried use pw-play while Ardour is playing. No impact. I suspect the problem in my particular case is that espeak uses a 16kHz sample rate, and PW is resampling and doing something wrong.

Your next diagnostic step should be to open a terminal while Ardour is running (and the other DAWs) and run pw-top there. Trigger a beep/notification/whatever, and observe the behavior in pw-top … is the sound generator running at the hw sample rate? Also, what quant(um) size is in use for the hardware?

Your next diagnostic step should be to open a terminal while Ardour is running (and the other DAWs) and run pw-top there. Trigger a beep/notification/whatever, and observe the behavior in pw-top … is the sound generator running at the hw sample rate? Also, what quant(um) size is in use for the hardware?

I’m not really that good at the understanding of the audio related stuff, so I’ll try my best.

I’m running Ardour at 48kHz, the sounds that are produced by the system are using 44.1kHz, the espeak tool that I’ve used for text-to-speech sound generation is running at 22.05kHz.

When I’m executing

$ while true; do espeak 'test' && sleep 1; done

During a running session, the sound stutters, like with the system sounds.

Then I’ve tried running Ardour via the pw-jack

$ pw-jack -p 1024 -s 44100  ardour8

If I got it right, then both Ardour and the system should produce sounds at the same sample rate (44.1), but the stuttering is still there.

Well, actually, it’s not only system sounds, from time to time, I’m trying to listen to some tracks from let’s say Spotify, in parallel to the track I’m mixing to compare the loudness etc, and it’s becoming impossible with Ardour because of this thing

The next thing I’ve tried: I’ve listened to some mp3 in parallel using pw-play, and it has worked out perfectly well, both sounds (Ardour output and pw-play) were just playing along, this is what it looks like in pw-top:

R   89   1024  48000 966.7us   5.1us  0.05  0.00  1221    S32LE 2 48000 alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-input-0
R   50      0      0 163.0us  24.1us  0.01  0.00    0                   + Midi-Bridge
R   54      0      0  44.9us 117.1us  0.00  0.01    0    S32LE 2 48000  + alsa_input.pci-0000_00_1f.3.analog-stereo
R   64      0      0  97.0us  12.0us  0.00  0.00    0                   + bluez_midi.server
R   79      0      0 188.3us  65.1us  0.01  0.00    0    S16LE 1 48000  + alsa_input.usb-Lenovo_ThinkPad_USB-C_Dock_Audio_000000000000-00.mono-fallback
R   88      0      0  40.9us  46.1us  0.00  0.00    1    S32LE 2 48000  + alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-output-0
R  143      0      0  52.5us 562.2us  0.00  0.03    1                   + ardour
R  232   4800  48000  55.0us  82.7us  0.00  0.00    0    F32LE 2 48000  + pw-play

but when I’ve tried the following, the stuttering appeared again

$ while true; do espeak 'test' --stdout | pw-play -; done
$ pw-top
R   89   1024  48000 321.4us   1.5us  0.02  0.00  1221    S32LE 2 48000 alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-input-0
R   50      0      0  56.1us   8.3us  0.00  0.00    0                   + Midi-Bridge
R   54      0      0  13.4us  42.0us  0.00  0.00    0    S32LE 2 48000  + alsa_input.pci-0000_00_1f.3.analog-stereo
R   64      0      0  60.3us   4.1us  0.00  0.00    0                   + bluez_midi.server
R   79      0      0  65.1us  24.9us  0.00  0.00    0    S16LE 1 48000  + alsa_input.usb-Lenovo_ThinkPad_USB-C_Dock_Audio_000000000000-00.mono-fallback
R   88      0      0  12.1us  16.3us  0.00  0.00    1    S32LE 2 48000  + alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-output-0
R  143      0      0  19.5us 179.7us  0.00  0.01    1                   + ardour
R  232   2205  22050  45.4us  81.2us  0.00  0.00    0    S16LE 1 22050  + pw-play

I’ve tried finding something out in pw-top but all the DAWs looked the same to me, I can also make some screenshots if you expect that I could’ve missed something there, that can absolutely be the case, but when I’m loading a DAW, it just looks like that:

R   89   1024  48000 418.5us   5.2us  0.02  0.00  1221    S32LE 2 48000 alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-input-0
R   88      0      0  86.4us  52.9us  0.00  0.00    1    S32LE 2 48000  + alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-output-0
R  143      0      0  98.4us 167.8us  0.00  0.01    0                   + REAPER
R   89   1024  48000 245.5us   1.1us  0.01  0.00  1221    S32LE 2 48000 alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-input-0
R   50      0      0  38.8us   6.1us  0.00  0.00    0                   + Midi-Bridge
R   54      0      0   8.2us  30.2us  0.00  0.00    0    S32LE 2 48000  + alsa_input.pci-0000_00_1f.3.analog-stereo
R   64      0      0  55.6us   2.7us  0.00  0.00    0                   + bluez_midi.server
R   79      0      0  45.1us  17.5us  0.00  0.00    0    S16LE 1 48000  + alsa_input.usb-Lenovo_ThinkPad_USB-C_Dock_Audio_000000000000-00.mono-fallback
R   88      0      0   9.6us  12.1us  0.00  0.00    1    S32LE 2 48000  + alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y81P4VP063F930-00.pro-output-0
R  143      0      0  12.4us 146.1us  0.00  0.01    1                   + ardour

Apart from extra devices that are not used by Reaper, it looks more or less the same, and I’m not sure if it can be the reason, but I tend to doubt it.

I’ve also checked what the whole setup looks like in Helvum, and actually there I’ve seen the most noticeable difference between Ardour/Mixbus and other DAWs. Both Reaper and Bitwig are represented as a simple entry with one stereo input and one stereo output, while Ardour and Mixbus are both complex entries with a lot of inputs and outputs for each track/bus, metronome, master output, etc, I’m not sure though, if it is relevant for my issue, but to me, it seems like it can produce a way more load on Pipewire.

UPD: Another interesting observation I’ve made, was that when I run two DAWs in parallel, and both of them are playing ~20 tracks with a lot of reverbs, they are playing along just fine, and I can hear no issues at all, no stutters, freezes, nothing stops to respond. That most probably means that my idea about overloading Pipewire is wrong

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.