But when you bypass the plug-in in ardour, the host (e.g. Ardour) tells the plug-in about the bypass state. So, if ardour doesn’t run the plug-in then the DSP load contributed by the plug-in will obviously drop to less than when it is normally running, but if ardour continues to run the plug-in, the plug-in may have decided that since it has been bypassed it no longer needs to process the audio in order to conserve CPU resources, and therefore the DSP load will drop. In addition the DSP load contributed by a plug-in may vary when it is not bypassed and just running normally due to all manner of different variables, therefore the idea that it remains the same when it is bypassed is kind of nonsensical in as much as ‘the same as what’?
The original pair of comments about this confusingly connects “disabled” and “bypassed”.
If the plugin is disabled, then its contribution to DSP load will vanish. I agree that if it is bypassed by an actual plugin bypass control, then that’s not necessarily true.
That would be a substandard plugin which one should not take live on stage and be wary of when mixing, since un-bypassing may cause dropouts.
Ideally DSP load is constant.
The ALSA option will always be an option, since Pipewire understands the device reservation scheme that was designed over 15 years ago. In that sense it doesn’t matter if distros “go Pipewire”.
Pipewire contains a lot of promise for the Linux audio (and video!) ecosystem, but at the moment, particularly when it comes to pro-audio and music creation workflows, it is still a work in progress. We should not forget the promise, but also not let ourselves forget that both in terms of user experience and actual bugs, it has a ways to go.
I don’t know that that is generally the case, in fact VST3 enshrines the idea that CPU load will vary dynamically - in some cases a plug-in can choose to freeze its processing when fed with silence for example. A plug-in’s DSP load can typically vary for a variety of reasons during ordinary processing anyway, so the idea that its the same when bypassed is as I said somewhat nonsensical since its not even possible to equate the state. To be pedantic, depending on the use case it could be said that a plug-in which burns CPU when its idle is substandard especially on e.g. mobile for example.
My point was that I just don’t think its a correct assumption anymore that the DSP load is constant
To be pedantic, VST3 standard has the silence flag for this case (and offline mode for batch processing)… but we are really getting off topic here.
Aye, and I’m a bit amazed that they could propose such sweeping changes to the audio ecosystem while leaving so many holes unplugged, but as you say, a work in progress.
Thanks for clearing up the disabled/bypassed phrasing. I was strictly talking disabling them on tracks that I’m not using. Since I use a template to start a project, not every plugin is necessary for each project. Glad to know that will lighten the load.
And I realized I’ve been running with a debug version. Compiling with the --optimize flag on seems to have given me about 15% more headroom on the DSP, now running below 60%. I still have a CPU sitting with 80% spare capacity, but I’m probably not understanding the DSP signal chain correctly and the need for it to be this way.
And it could be that some of these plugins are just hogs. In particular, the GxAmplifier-stereo plugin I’ve been using is pretty intense, and I use it on a number of tracks. I tested moving some of this over to Carla and it’s reporting the same kind of 50% load with just it and a delay going. The advantage to Carla is that I can run multiple instances and spread the load out over my system and use some of that spare capacity, at the expense of a much more complicated studio setup, but it does seem to be an option.
Well I’ll take that as a tacit agreement that plug-in DSP load is not constant, (and by implication therefore cannot also be relied upon to be constant or necessarily the same when bypassed), which was my original point. And does / did have some relevance when trying to diagnose the original or similar issues related to DSP load xruns etc.
Here’s a quick way to think abou the CPU load vs DSP load thing.
Imagine an insanely long buffer size just make it easier to think about. Say, 1 second. Your audio interface (or something else) wakes up the CPU and says “it’s time to process 1 second’s worth of audio”. The app responsible starts running and takes 0.98 seconds to do the required work. Then it goes back to sleep, waiting for the next buffer.
That’s a 98% DSP load (representing the fraction of the buffer time it took to process the audio data), and (if nothing else was going on) a 50% CPU load (the cpu is active for 1 second, then asleep for 1 second).
Obviously real world cases are a bit more complex than that, but this captures the disconnect between cpu load and DSP load.
2 Likes
Thanks, I think that actually clicked this time. So basically the DSP only has so much time to respond to stay real-time, so the time slice all the DSP modules have to complete their work is really… the inherent latency in the buffer size? Or something pretty close to that cause if it goes much more, we’ll hear it and there’s nothing worse than trying to play an instrument when the notes are lagging my fingers.
It cannot take longer than the time represented by a buffer to process the buffer (if it does, you get an xrun/click).
On most modern general purpose OS’s these days, about 80% DSP load seems to be about the point where things start to fall over i.e. even if things are running with realtime scheduling and the rest of the good stuff, it’s not reliable enough when buffer processing takes that much of the time the buffer represents.
The buffer size really only matters if you’re using MIDI-driven software synthesis. For recording only (*), you could use a buffer of many seconds if audio hardware allowed it (it doesn’t). For editing/mixing, large buffers don’t bother most people, even though technically it is making the plugin and DAW controls a bit more “sluggish” than they need to be.
(*) this assumes no monitoring via the software. If you’re doing that, then it’s equivalent to MIDI-driven software synthesis in terms of desirable latency.
Which is likely to be the case when using a guitar processor like GxAmplifier. The way you want to phrase the guitar playing will depend on the differences in sustain you get with amplifier settings, so you will want a reasonably low latency so you can hear the processed guitar while playing and recording.
1 Like
That’s the usual trouble and my only trick about this situation is when possible to use an external pedal or amp of multiFX to get a reasonably close to hope sound for a take and record every gtr take on 2 tracks, one from ext processed sound and one for DI thus I may (and usually will) re-process/reamp/refx the DI but at least it was initially played with a decent sound close to the desired on and the bends, slides, hammers and other casual tantrums were into play 
Check the kernel preemption configuration. With a buffer size of 1024 you should not need full PREEMPT_RT, PREEMPT FULL or PREEMPT LAZY should run fine.
I’m testing this now as a comparison. Set my NI interface to 1024 period size, 48k using pw-metadata.
Created a new session with 8 tracks, added GxAmplifier-stereo and C*Scape stereo delay to one track, Gx Alembic to a second track (mimics guitar and bass tracks);
all 8 tracks have ACE EQ and either ACE Compressor or DYN500 (proprietary) plugin.
My kernel is using lazy preemption, I set the governor to userspace and locked the clock frequency to a rate that was upper mid-range.
DSP is sitting at 8% while recording to or playing back all 8 tracks. CPU shows 92% idle.
Same session setup but at 96k sample rate.
My DSP increased to 17% and CPU now shows 85% idle.
That is the binary from ardour.org, so an optimized build. Pipewire version is 1.6.8, USB connected audio interface is set to “Pro Audio” mode (which does change the interrupt behavior of pipewire according to what I have read; it should make it behave more closely to traditional jackd).
I could add a few synth plugins, they may be somewhat DSP heavy. One track of GM Synth, one track of setBfree, one track of Odin2 synth.
That did not change the DSP usage that I could see. I didn’t have any MIDI data coming in, so I connected a keyboard to all three MIDI tracks and just sent in a lot of key banging, it didn’t seem to change the displayed DSP usage more than 1%.
Just my data for comparison.
1 Like
Hey Chris, thanks for that info. What kind of processor do you have?
I cleaned up my project today. I did have a track or two that had a number of effects going that I started the project with but then shifted over to other things and didn’t disable them. My DSP is now hovering around 50%, and I have about 8 tracks going as well, with a few GM synths with amps on them, guitar processing on a couple channels, it’s around the same load you’re saying, maybe a little more, so thinking you have a better CPU than I do. Mine is a bottom of the line 12th gen i5, 12400. It’s great for just about everything I do, but in this instance, the clock rates are a bit too slow on it burst through the DSP processing. I may consider upgrading it… I just really hate the e-cores Intel started putting in and bought that specific CPU cause it didn’t have any. But if this is becomes an issue, I’ll pick up a newer CPU and swap it out. I think my mobo will support a 13th gen i7 or i9, but an i9 would be a waste for 99% of what I do. It’s just in this one instance were CPU clock speed appears to be king.
I have a Xeon 5650 from 2010. Max 2.6GHz, but I locked it to 2.1GHz for this test, since fixed frequency is better than max frequency if there is a possibility that the CPU clock might get changed, for example because of thermal throttling. Dual 6-core CPUs.
Unlikely. You are often better off with a slower clock speed, but no turbo, locked to a single frequency using the user space governor.
Hmm, interesting. Definitely in the same class of CPU core capability. I believe the 12400 core runs at 2.2Ghz and turbos to 3.8Ghz (EDIT: Actually power saves at 800Mhz and turbos to 4Ghz). I keep my system clean and have a good air cooler so I won’t get thermal throttling. My temps run around 30C-40C under normal load, topping off around 55-60C during a compile with all cores at 100%.
In testing yesterday, I did see my DSP load drop into the 20’s, but then it’d bounce back up to the 60-70 range, and the average seemed to be around 40-50. That was at 96k SR w/2048 buffer size. I haven’t been able to run stable at 1024 buffer size and 96k, and even 2048 had it’s moments of instability, which is what started this whole mess. I did build an optimized version yesterday and that did get me an extra 15% or so of headroom and back down into the safe operating areas, but I haven’t reached the %'s you’re reporting, or even got close.
So you’re saying the context switching of the core going into turbo mode would be detrimental to the DSP load? Given how much time there is in processing slice, I can see some advantage to locking it down. I can certainly see not wanting to lock it in turbo mode. I’m not quite sure how to do some of the stuff you’ve mentioned, but it all makes sense and will definitely look into it more and figure it out.
Thanks! Lot of good info coming from this discussion, despite the occasional sidetrack.
Ok, did some digging (well, actually asked AI to help with the system arcanery) and you’ve hit the answer. After messing with the command line a bit and verifying my freq’s I went to system settings and set the CPU to performance, and bam, 9% DSP load. I’m not sure what the CPU was configured for before but it was probably balanced between performance and powersave (my cpu does not support userspace), which put the CPUs at 800Mhz to ~1.5Ghz and ready to respond a little better than in powersave mode. Putting into performance mode sets the all the core frequencies to 4Ghz by default, so when Ardour starts running, it’s already cranking away. It looks like I can even run with a 1024 buffer now, but I’ll need to test more for that.
I will update the OP with a TLDR section with all this great info. I will probably setup Ardour with a wrapper script to set to performance mode before starting, and set it back to balanced when exiting.
Thanks all for suffering through this with me and getting to right answer. Very much appreciate it.
EDIT: Well, I can’t seem to edit the OP, so will summarize here:
- Check your CPU power and frequency settings to limit the number of CPU frequency changes. Lock it down to one frequency if you can. How that is done is dependent on your operating system. Recommend using an AI bot to help with the syntax if you’re unsure. Chose a comfortable setting that gives you the performance you need without stressing your system too much. 2.1Ghz was reported to produce good results, but that is highly CPU dependent. There may also be system tools to set your system into a “best performance” mode.
- Disable all unused plugins. Check all your tracks to be sure you don’t have any stragglers.
- If you’re compiling from source, be sure to use the --optimize flag
- There is a reported buffer setting issue with the JACK/Pipewire configuration that has yet to be confirmed and dispatched by the Ardour team.
Regarding this sidenote my sidenote is: dynamics processing at 96kHz later downsampled to 44.1kHz could provide smoother/better results that can be clearly heard and enjoyed by (my) human ears. (Compressing, limiting, clipping.)
Or if you’re using a plug-in that provides a simple cookbook EQ without properly decramped filters, processing at 96kHz will move the region where the digital filter response becomes cramped (when compared to the equivalent analogue response) out of the audible range.
(But if you’re sample rate converting, that might add artifacts of its own, so as usual there’s no simple rule of thumb that says ‘48kHz good 96kHz bad’ or vice-versa. It depends on the context. Id say the best general rule is don’t sample rate convert unnecessarily if you can avoid it, and always use good quality plug-ins)
2 Likes