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

From: Ken Restivo <ken@email-addr-hidden>
Date: Thu Feb 01 2007 - 02:14:31 EET

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

On Wed, Jan 31, 2007 at 01:46:17PM +0200, Sampo Savolainen wrote:
> Quoting Ken Restivo <ken@email-addr-hidden>:
>
> > -----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-----
Received on Thu Feb 1 04:15:02 2007

This archive was generated by hypermail 2.1.8 : Thu Feb 01 2007 - 04:15:02 EET