[PD] How to increase audio latency on linux?

Roman Haefeli reduzent at gmail.com
Mon Dec 10 14:46:13 CET 2012


On Mon, 2012-12-10 at 13:17 +0100, Lorenzo Sutton wrote:
> On 09/12/12 11:12, Roman Haefeli wrote:
> [...]
> > If my intent to have an as huge as possible latency in order to decrease
> > likeliness of drop-outs, it is still advised to use a low latency kernel
> > and run Pd/Jackd with realtime priorities? Or would I be better off then
> > with standard settings?
> You probably already know/do this.. but there are a couple of factors 
> which can create dropouts/clicks which seem independent from 
> bleeding-edge-realtime etc. settings:
> - CPU: be sure to set it to "performance" and *not* on demand

Yeah, it appears to me that only since a few years this is an issue for
me on Linux laptops (not so on non-mobile computers). Somehow the CPU
frequency scaling manager is too slow for Pd, so often it sticks to the
lower frequency, although Pd is using 100% CPU (or probably it is
related to multi-core CPUs? I don't know).

$ sudo cpufreq-selector -g performance

seems to get rid of the issue.

> - Lots of (Pd) gui objects (e.g. sliders, numberboxs) manipulation/updates.

The reason I'm interested in huge latencies is exactly because of this.
I'm using Pd in non-interactive setups, so the huge latency doesn't
matter. On the other hand, the big latency allows for doing a lot of
stuff in zero logical time without risking drop-outs. One example is
load new presets while the patch is running, which means reading and
parsing a text file, setting loads of number boxes and sliders, loading
a number of soundfiles into [readsf~]s or [readanysf~]s, all this in
zero logical time. With low latency, this is much more complex while
avoiding drop-outs (like loading the preset step-by-step, for instance).

Roman 




More information about the Pd-list mailing list