[Ardour-Users] Ardour's DSP load rising and falling whilst idle [WAS: Denormals]

Robin Gareus robin at gareus.org
Sun Jan 1 08:41:24 PST 2012

On 01/01/2012 04:33 PM, Q wrote:
> -- With the session I'm currently working on, Ardour's DSP load keeps
> rising from ~50% to near/actually at 100%. This is making it impossible
> to mix as I cannot run playback for long before it grinds to a halt
> -- Sometimes the session will run fine for a little while and the rise
> in DSP load starts when I stop the transport, although given the next
> point I wonder whether this is just a coincidence
> -- Ardour's DSP load for this session will rise to 100% when the
> transport has been stopped for some time, then drop (sometimes as low as
> 30ish percent, but usually about 50%). It will keep on rising and
> falling periodically, although I've not ascertained any frequency to it
> -- This rising/falling of DSP load occurs whether other programs are
> running or not. Looking at the Task Manager, no other processes are
> using anything more than 1% CPU (and there's only one or two processes
> doing even that) when Ardour's DSP load goes up to 100%
> -- All tracks and busses in the session have "Protect against denormals"
> and "Use DC bias" selected and I have "Stop plugins with transport"
> selected (although apparently this feature might not actually do
> anything). The processor denormal handling features are disabled (but
> not when using A3 -- the same load issues are seen in A3 as well,
> although the load is not as high and it only rarely goes over 90%)
> -- I'm running 2.8.12 built from source under Ubuntu Studio 11.10. The
> machine is a Phenom X4 9950 with 4 GB RAM and it is running at the full
> 2.60 GHz all the time (the cpufreq panel applet says it's running On
> Demand, but I think it has no choice but to run at 2.60 GHz)
> -- Jack is running in RT mode, 2048 f/p and 2 p/b, 44.1 kHz, duplex
> (can't change that: when it's set to playback only, it'll only allow the
> default device, which isn't my actual soundcard), Unlock Memory selected
> -- Disabling plugins and re-introducing them has not turned up any which
> are obviously causing the spikes in DSP load. I'm using EQ10Q (many
> instances), Invada Compressor (several instances), IR (two), TAP Tube
> Warmth, Invada Stereo Phaser, MS Spatialiser (a couple), Invada HPF, C*
> AMP VTS, C* Cabinet II, Richard Furse Simple Delay Line (a couple),
> Invada Delay Munge (a few), Tape Delay Simulation

[Wow, quite an impressive accurate bug summary. -- disclaimer: I'm still
still hung-over :)]

> I have just de-activated all plugins in the session and have watched the
> DSP load for five or ten minutes. With Ardour idling and no plugins
> activated, the DSP load is generally 5.0 to 5.5%, but periodically
> doubles to 10% and over. As above, there are no other processes using
> much CPU when this happens.

How did you 'de-activate' the plugins?

Did you remove them or only bypass them?

I'm not certain, but..
Isn't deactivating a plugin/route in ardour2 equivalent to bypassing it?
Isn't the plugin's processing function executed anyway, also for
bypassed plugins?

A quick test here (A3) seems to indicate otherwise, but there's quite a
few options hidden somewhere and I recall from some previous email-list
communication that plugins are can be run continuously.

> Yeah, 10% is nothing, but it seems that something is causing these
> periodic rises in Ardour's load, which is greatly amplified when there
> are a load of plugins activated.
> Further investigations with re-introducing plugins seems to indicate
> that the three instances of Invada Delay are the biggest problem. They
> cause a considerable increase in DSP load, which is pushing these spikes
> to near 100%. Without them, when the load spikes it's only going from
> around 25% to around 50%, which doesn't cause any xruns. A single Invada
> Delay pushes the load up to 75%. Without the spikes it wouldn't be an
> issue, but for the time being I'll have to find an alternative to the
> Invada Delay so that when the load spikes inexplicably it's not grinding
> the machine to a halt.
> So when Ardour is ostensibly doing nothing, what could be causing this
> periodic rise/fall in the DSP load?

All in all, it smells like a Denormal issue in some plugin(s).

Denormals usually show up after some period of silence:
Once there was some input,.. now the input is silent and the
[plugin] algorithm does lots of near-zero calculations. -> Denormals.

Depending on the plugin, it can take quite some time until they show up
(esp. on delay-lines it may be 90+ seconds). Also depending on the
plugin (internal feedback) they may or may not settle down after a while.

> As ever, any hints, helpful suggestions or advice gratefully received.

There's a small app called 'bitscope' or 'bitmeter' that can display
denormals on JACK ports: http://devel.tlrmx.org/audio/bitmeter/

But I'm not sure if it is helpful to debug your problem because, IFF the
FPU supports it, Ardour will flush the denormals to zero before pushing
them on the jack-port.

Could you post the ardour-session (minus the audio-files) somewhere?
Since you say the problem persists even when Ardour is idling this
should be reproducible on other machines.

> Thanks in advance,
> Q
> PS If this too general or not Ardour-specific let me know and I'll take
> it over to LAU.

Digging in the dark:


adds 1.0e-27f; to each sample. Could that be too small a bias?

"I [Fons] use something like 1e-20f, which is 400dB below normal levels"


Are you chaining Plugins?

AFAICT the DC bias is only added before the first plugin. A 2nd plugin
in the chain may actually be prone to Denormals if the first plugin
removes the DC offset.


Are you using phase-inverts in your ardour session? Ardour3's route.cc
subtracts the bias if the phase of the route/channel is inverted, A2
does not. It may be that the bias is effectively canceled out in the

I hope I'm not just adding to the confusion..

More information about the Ardour-Users mailing list