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