[linux-audio-user] Shaving CPU cycles

Sampo Savolainen v2 at iki.fi
Wed Jan 31 06:46:17 EST 2007

Quoting Ken Restivo <ken at restivo.org>:

> Hash: SHA1
> I've run into an 80% DSP problem on my machine.
> This poor little PC doesn't have enough CPU power to run all the
> softsynths and LADSPA plugins I tend to use. When JACK gets to 80% DSP
> usage, all hell breaks loose. If I up the latency, then my CPU usage goes
> down, but the system is unplayable (too much latency).
> So. What kinds of things would be best to try to squeeze some life out of
> this underpowered 1.66Ghz Core Duo? I have a list, but I'm not sure which
> would be the first, second, third order improvements and I'd like to try
> to conserve time, especially if the end result will end up being that I
> have to sell this PC and get a new one anyway. Do I have the priorities
> right?

There's a lot of things to do. "underpowered" is not a word I would use for
a core duo processor.

My list of things to do first would be:
1) SSE. Make sure all synths and ladpsa plugins are compiled with SSE
   (This is rarely done in distributions because SSE is not supported
    by all currently used x86 processors, we're getting quite close to
    that though)

2) Sharing. Instead of running separate reverb plugins on each track,
   create reverb buses for a small number of different types of reverbs.
   Usually there are two: one long reverb and a short one. Then use
   sends to send appropriate amount of the signal from each track to
   the effects bus.
   You can share other effects too, reverb is a natural choice for
   "sharing" as many mixes sound actually better with a coherent reverb
   space instead of having multiple varying reverbs.

3) Freezing. This means that in for example ardour, you can pre-render
   the effect of the plugins on a track. This can lower the DSP usage
   very much if you have tracks with heavy processing.

> 1) Try jackdmp instead of jackd

That might help.

> 2) Try DRM or some kind of accelerated graphics for Xorg

Accelerated graphics is a good idea.

> 3) Blindly chase "latest and greatest" versions of things like kernel
> 2.4.20, latest jackd, svn freebob, etc.

I expect you don't mean 2.4.

"Blindly chasing" is never a good idea, but there has been a lot of work
towards better realtime performance in the latest kernels. I strongly urge
you to try a newer kernel if you are running < 2.6.17, especially if it's
without ingos' RT patches .

> 4) Try messing around with PCI bus latency

That might help a bit. But keep in mind that DSP usage of 80% is really
high. It doesn't leave your computer much headroom for other tasks, or even
plugins which might periodically use more CPU cycles than normally (=which
is in fact a sign that a plugin is not "academically" real time safe). In my
opinion 80% is about the maximum of DSP usage you can expect to be stable to
work with.

Remember that with the rest of the time, the CPU, operating system and the
software need to do tasks like update GUI windows, run the disks, complete
network traffic. Without time to complete these tasks, your computer will be
unresponsive (altough it might still will be processing audio, though ;) ).


More information about the linux-audio-user mailing list