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?
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.
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.
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.
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
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.
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.
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).
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.
Well, there are users who run Ardour at even higher sampling rates at smaller buffersizes, and others who do the same with Mixbus, which is even more resource intense, which is why my first thought was that your system isn’t optimized for low latency, pro-audio (which may very likely still be the case).
Yeah, I would agree with you. I don’t seem to be getting very good performance out of this and it’s confusing me to have so much capacity not being used, and I’m sure others are going way beyond what I’m doing. And I understand that a better system than mine would handle the buffer management ok, but are they all doing it in JACK/Pipewire? As I’ve said, the buffer issue is real, but the rest may be in my system, or worse, the changes I made may have some unintended consequences, which is why I really posted.
I may have to explore some other options to decide the best way to go, and I may need to shift to Kxstudio or something like that. I’m not running the real-time kernel, which could be an issue, and I may try to switch over using the Ubuntu studio tools for that. I used them a while back to switch to the real-time kernel on this build and didn’t see much difference in performance, and that kernel causes strange issues with other things I use this system for. I’m about ready to rebuild this system, though, and there may be better options. Need to at least look at Kubuntu 26.06 and the new kernel.
I was thinking last night that I may try to move some of the plugin management over to Carla or something like that, and just use Ardour for recording raw audio. Would complicate my setup, but might give Ardour the headroom it needs on my system to respond. MIDI and automation has been a little problematic too.
For the record, here are my system specs. Pretty low end now, but other than kicking off a compilation when every core goes 100%, I never see my CPU being the bottleneck in any work chain. There’s always extra processing power available. You also may want to consider doing some of your audio processing on the GPU someday. It’s better for that kind of array processing and there’s a lot of power just sitting there waiting to be used.
Operating System: Kubuntu 24.04
KDE Plasma Version: 5.27.12
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13
Kernel Version: 7.0.0-28-generic (64-bit)
Graphics Platform: X11
Processors: 12 × 12th Gen Intel® Core™ i5-12400
Memory: 31.2 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3070/PCIe/SSE2
Manufacturer: ASUS
I just got a Focusrite Scarlett 4i4 4th gen interface. I had a second gen but it just sounded flat. This one does sound better, especially with my acoustic. My electric doesn’t matter too much since I play through plugins anyway. In hindsight, I should have done a little more investigation and maybe went with an Audient which I think would have given better vocals, but that was a few hundred more. Might have been worth it though.
I don’t seem to have any trouble with it though. Recording is fine and it’s just the DSP processing that is causing issues with it when I’m playing guitar through it and using the plugins for effects. I record the raw audio so I can change things up later if I want. As Robin was saying though, all the plugins count against my DSP load, even the ones I’ve disabled… and that needs a little rethinking.
I also know I can dump the guitar track to an audio track and just delete the plugins to lighten the DSP load, but that’s also why i’m thinking of moving them out to Carla or something that does the processing outside of Ardour.
Oh, on this, I’ve modified Ardour to set set the audio interface to how I want it in Ardrour so they agree. Now when I change the buffer size, it changes Pipewire to match and everything is in synce. I’ve also added in sample rate changes so I don’t have to bounce to the command line when loading files of different sample rates.
I’m sorry, but as the original author of both JACK and Ardour, I really cannot accept your analysis here.
As was previously discussed, Ardour uses the JACK API only (for now) to interact with a JACK server, whether that JACK server is JACK1, JACK2, or Pipewire. I understand that you’ve modified our code to use the Pipewire API to control the Pipewire buffer size, but absolutely nothing about the JACK API side of this has changed in more than a decade.
The “interface” we present for JACK is spartan by design, because we believe that there are already much better, more complete and continually evolving tools for configuring JACK (or Pipewire) than we can or want to provide. This has always been true, ever since QJackctl appeared (20 years ago, perhaps?) We deliberately leave server configuration to those other tools, and have no plans to change this. If Pipewire is providing your instance of Ardour on your machine with the wrong buffer size in response to any JACK API calls, that’s a problem with Pipewire and should be fixed either with Pipewire configuration tools, or if necessary with fixes to Pipewire.
Pipewire is different from JACK in one very important way: it was designed to be able to run multiple clients with different buffer sizes, all “on top of” a hardware buffer size that might or might not correspond to what any of the clients are using. This is very convenient (as macOS users have known for decades), but can be undesirable in pro-audio situations with some hardware on some systems. Pipewire interprets JACK buffer size requests as being per client, not server-side, unlike JACK1 or JACK2.
As both @x42 and I have stated previously, supported by the lead Pipewire developer, we consider the JACK API to be the canonical and only way to interact with a JACK server, and if there are differences in behavior with other JACK implementations, that’s an issue to be resolved in Pipewire.
@x42 also made a simple request upthread for you to try this with the ALSA backend, and you reported that this still saw high DSP load numbers. This absolutely confirms that the entire buffer size issue, while potentially real, is a red herring here. If your system, when using the ALSA backend (i.e. “directly” interacting with your audio hardware) still shows this behavior, then it’s an issue with your system configuration.
This is cool, but because of Pipewire’s design, also problematic: again, unlike JACK it is designed to offer per-client control over such things, and thus using the Pipewire server for a differernt sample rate than the hardware is running at may work but could (potentially) just cause PW to resample the audio streams to/from that client. We never added SR control to JACK because it is a wickedly hard problem for useful multi-client configurations - expecting every possible JACK client, no matter how small or complex, to respond to SR changes was judged by JACK developers as too much.
I believe that while investigating/trying to fix this, you should (or even must) stop using PW and conduct your tests with the ALSA backend, eliminating any possible wrinkles caused by PW itself. You will find the “true bottom” for your system doing this, and once you understand and control that, you can reintroduce PW into the question and see what impact that has.
The last thing I want to do is get into a pissing contest with you on this. I’ve said what I’ve said and I kind of stand by the analysis, cause even the comments in the code imply the author really didn’t think much of Pipewire, but I’ll just leave it there. I submitted my changes to you in what I intended to be a quiet manner because I knew they needed a higher level look from someone who understands the whole system and all the different interfaces. I really didn’t want to get into this on this thread. I just wanted to know if anyone else is sampling higher than 48Kz in this configuration, which, I have not actually gotten confirmation on yet from anyone actually doing it, but I knew this was going to bleed over into the interface. My appologies.
Noted. Based on everything I’ve seen, that is probably a better course of action, though since many distros are going Pipewire, I’m not sure how long you’re going to be able to carry that thought process. I think at some point you’re going to have to give more support to this interface, but that’s just my opinion, and you certainly know the market better than I. I know a clean API would be much better and that the pw-metadata route is bit of a hack, but it does work to some extent, and makes working in Ardour a lot easier, for me at least. Maybe they’ll come up with something better in the future.
It is 100% correct, since we control whether a plugin is active or not, and the behavior of the plugin, if it remains active, is extremely unlikely to change very much unless the user changes settings.