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