New subject: [linux-audio-user] Shaving CPU cycles

31 Jan 2007

Quoting Ken Restivo &lt;ken(a)restivo.org&gt;rg>:

...
  -----BEGIN PGP SIGNED MESSAGE-----
 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
   support.
   (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 ;) ).

  Sampo

Re: [linux-audio-user] Shaving CPU cycles