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