Ardour 9.7 w/96k Sample Rate with JACK/Pipewire

Installation & Configuration Linux
#1

Is anyone successfully sampling at 96k with a JACK/Pipewire configuration? Since having the brilliant idea to start sampling at 96k, I’ve just run into all sorts of issues with Ardour and things just not behaving correctly.

I’m mainly getting a bunch of xruns and warnings that the latency is ambiguous. I’ve set Ardour to use all the cores it can, but my DSP percentage runs around 60%-80% all the time while all 12 of my cores are running less than 20% load, so something is not being used or computed correctly. I never see a single core even bounce up over 30% while recording or playing back. At 48Kz, i used to run around 40%-60% DSP load and very rarely had any xruns, but the default 1024 buffer size wasn’t an issue and my system could handle it, but at 96kz, it starts puking pretty badly, so I had to dig into why Ardour kept setting the buffer size back to 1024.

Disclaimer Time: I’ve modified Ardour to set JACK/Pipewire to the file sample rate when it loads the file (easy to do, just issue a pw-metadata system call from within Ardour). I also had to fix the buffer management as Ardour would not use any other buffer size than 1024, even if the dialog box occasionally showed it being different, under the hood, things were still running at 1024. So I’ve set Ardour up to be able to modify the sample rate and buffer size without going to the command line as it doesn’t seem to read the system very well either.

Sorry, not trying to get into a debate on what Ardour does or doesn’t do or if it should or shouldn’t. My fear there is that there is something else that needs to be done to correctly fix the buffer issue and something is still holding onto an incorrect value somewhere, which may be affecting my DSP loads and CPU utilization and confusing Ardour.

So I’m curious if anyone is successfully configuring a session to use 96/khz with a buffer size of anything other than 1024 samples. Are you seeing DSP loads below 50% and decent CPU utilization? Any xruns?

#2

As comparison, how does your system fare if you use Ardour’s ALSA backend instead of pipewire at 96kHz?

–

PS. Unless you make music for rats or dolphins there are only disadvantages of using sample-rates > 48kHz. I expect none of your actual hardware can do more than 20kHz and most transducers will cause artifacts for signals > 20kHz.

#3

I really haven’t tried to go back to ALSA. I like Pipewire and want to keep using it, but I do see in the code that you all made some assumptions in it that were very true when you started implementing that interface, but I don’t think are valid anymore.

My main reason for going to 96k is that I expect to have ‘fix’ some performance limitations in my skillset that may require more samples to do properly, and I don’t want to get to the end of a 48k project and find out that I should have started it at 96k and have to redo it.

So just kind of trying to figure out what’s going on here. You should take a look at the target_buffer_size attribute on the JACK interface. That appears to have been the culprit keeping everything at 1024, and I know the buffer size and sample rates are affecting the DSP loads and I just don’t understand why the DSP load is so high and performance is bad when my CPU is sitting 80% idle.

I see you have some pretty complex latency and loading calculations going on inside Ardour and didn’t really want to get into that aspect of it, but things have just gone downhill pretty bad since switching and I’m spending a lot more time fighting the system than making music. If going back to 48k is the answer, well, ok, but that don’t seem right as I’m sure other configurations are doing this just fine.

#4

And I don’t mind helping out to. If I’m one of the few using this interface, I’m willing to help you all improve it and I’m setup for it now.

#5

I was suggesting it just to see if it is a problem with pipewire and 96kHz or your system/setup in general. If Ardour/ALSA has the same issue then it’s not pipewire’s fault.

Ardour Menu > Window > Audio/MIDI Setup, change backend to ALSA, and if pipewire isn’t currently playing some audio to the soundcard, it’ll yield it to Ardour. I suggest to give it a try.

#6

Ok, same behavior in ALSA. Soon as I start the engine, DSP immediately jumps to around 70% even with nothing running. I notice a lot more buffer options on this as well, but 2048 seems to be the smallest buffer I can run at 96k. Higher than that and I start noticing some lag in the system response to notes.

Hmm, could it be a plugin? These are the plugins I’m running in this project.

General MIDI Synth: Couple instances of this one for strings and base
SetBFree
GxAmplifier: Couple of these on a couple guitar tracks
GxTubeDelay on one or two guitar tracks

Also using these, but they are disabled:
LSP Compressor Stereo
GxReverb
GxTubeScreamer

#7

keep in mind that bypassing plugins does not (usually) lower DSP load. Ideally plugins have constant DSP load regardless if they are active or not. This way you can automate a plugin’s bypass/enable without risk of adding x-runs.

#8

Check Ardour Menu > Window > Plugin DSP Load.

Maybe another thing to try: Ardour > Preferences > Performance > Power Management, CPU DMA latency. Set it to 2ms (or some low value).

You may have to install 99-cpu-dma-latency.rules from ardour/tools/udev at master · Ardour/ardour · GitHub if your user doesn’t have permissions to set it.

#9

Plugin DSP load is all green, well on the low side for each one. Combined they could add up to the percentages I’m seeing, maybe. Doesn’t correlate with what I’m seeing on the system side for CPU utilization though.

I’d already set the CPU DMA to Lowest (Prevent CPU Sleep States) before posting but it didn’t have any effect.

#10

Ardour has to use the system set buffer value. That is how the JACK interface works.

Ardour is pretty strict about the JACK API, anything which is not valid with pipewire is likely a pipewire error in the JACK implementation compared to jackd.

DSP load is based on how much of the available processing period is left when Ardour finishes all the required audio processing. At 96k samples/s compared to 48k samples/s the time available is half for the same buffer size. Going from 40% to 60% when the available processing time is half what it was previously isn’t all that bad.

CPU utilization calculated by the OS is different because it measures utilization over the entire measurement period. What you care about is utilization over the amount of time you have to process the audio, because that is what determines if you miss the deadline to fill the buffer and cause an underrun or not.

If you double the buffer size compared to what you used at 48k, then the latency is the same, and the processing load will be equivalent to doubling the number of channels when compared to 48k (because there are twice as many samples to process).

#11

No, that’s how it may have worked at the beginning, but that assumption is no longer valid, and internally you have three variables tracking buffer size; the actual, target and desired, and those three are not in agreement in the current baseline. All I had to do was set the target value in I believe the JACK_ENGINE::set_buffer_size() method to get it to hold the buffer change. It’s also a trivial mater to issue a buffer size change from within ardour using the pw-metadata command, along with other parameters that it supports.

Well, again, there are a lot of old assumptions going on in the JACK/Pipewire interface and it doesn’t look like it’s gone through much testing. Things are just assumed that the system will take care of it and everything is kicked to the user to figure out how to set it up. As a result, the JACK/Pipewire interface is spartan at best and no attempt has been made to make it like the others even though a lot has changed since it was first introduced… sorry, not trying to hit the team, you’ve got a lot of stuff going, but that’s how I see it.

But as it is in the official baseline now, no matter how you set the system, Ardour will continue to override the buffer size with the target value, which never gets set to anything other than the initialization value of 1024. I’ve tracked that with debug messages. But all three variables tracking the buffer size need to agree, and I’m not sure I got all the angles of it covered, which prompted me to ask if anyone else has gotten this configuration to work. If you’re sampling at 48Kz or lower, you’ll probably never notice it, but going to 96K exposed it.

Sorry, but I’m finding that a little hard to swallow when I see 80% of my system just sitting there while ardour is complaining that it doesn’t have enough time to process a few plugins, when 90% of the work of Ardour is expected to be done in the plugins to process audio. Ardour moves the raw audio data around, but a lot of the work is done in the plugins, so they need some priority and every resource they can grab.

I do agree though that there is a limitation here that is actual as my system clearly responds like crap with a few things going, but seems there could be better ways at tackling the audio streams that use the capabilities of the system. I have a pretty barebones system, but I put it through a lot more stress in other areas than Ardour should be demanding of it. It just seems that Ardour is not taking advantage of all the resources it has available. Maybe that true, maybe it’s not. If it is then I would like to know why and why it can’t be improved, even if I have to figure it out on my own.

And sorry, I really don’t want to get into a back and forth with you all about this. I’m just trying to get a usable system. But I’ve got over 40 years of systems and software development (retired engineer), and I even did some real-time audio programming back in the 80’s on a VAX 11/780, so I’m familiar with pulling data out of an A/D converter and demuxing it to usable audio. That doesn’t mean I know jack about JACK. I only say that to follow on with that I have a lot of respect for what you guys have done here and Ardour is a great tool. When I said going to 96K was a brilliant decision, I said that with a load of sarcasm and it may have been the dumbest thing I’ve done recently. Seemed like a good idea at the time, but I may have to rethink this as Ardour is not handling it very well. Just trying to figure out my path forward.