[linux-audio-user] Shaving CPU cycles

[Ken Restivo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jan 31, 2007 at 01:46:17PM +0200, Sampo Savolainen wrote:
> Quoting Ken Restivo <ken at restivo.org>:
> 
> > -----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)

I tried compiling CAPS plugins with the "fast CPU" options, namely:

CFLAGS += -fPIC -DPIC -O6 -ffast-math -funroll-loops -Wall -fPIC -DPIC -msse2 -mfpmath=sse -pipe -ftracer

And... it made the problem *worse*.

By far the biggest pig is my Rhodes sound. That is:
	fluidsynth -> CAPS AMP IV -> CAPS Cabinet II -> TAP AutoPanner -> CAPS Plate 2x2.

I also usually have one or two guitar tracks with CAPS Amp IV -> CAPS Cabinet II also.

As well as 3-4 fluidsynth instances, and Hydrogen, and Ardour, and Rosegarden, and whysynth (jack-dssi-host), and one or two AMS instances. And I haven't even started playing with PD or Csound yet.

> 
> 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.

Excellent idea. I'll try that.

> 
> 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.

Trading disk space for CPU cycles, eh? I tried that and had problems; the frozen track sounded awful. It seems like tracks are not "frozen" in real-time, but the frozen track had the same artifacts that the real-time version did. I'm probably not doing freezing correctly; I'll go back and read Ardour docs and play with that some.

> 
> > 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.

On my OpenWRT, yeah, but not on my Core Duo. Typo. I meant 2.6.20-rcN-rtX

> 
> "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 .

I'm at 2.6.19.1-rt15, with the RTC-lockup patch applied. Would 2.6.20-rcN-rtY be worth trying?

> 
> > 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 ;) ).
> 
> 

Thanks for all the ideas and suggestions!

- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFFwTDne8HF+6xeOIcRAgDnAKCcH7ioEqlm45XfpBUhoLQSzC69YQCdEGfh
p7ZXSiWf64ntrRj4HSmsAEY=
=BzVJ
-----END PGP SIGNATURE-----