________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Saturday, June 1, 2013 2:39 PM Subject: Re: [PD-dev] jack dbus?
On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
There's no other combination of frames/period and period/buffer you can use to get ca. 17-20ms latency without dropouts?
Not on the hardware I'm
using.
Any ideas on what is causing the discrepancy? It has to be either a bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't in realtime mode or something more subtle). I wouldn't think it has to do with your specific audio device as JACK uses ALSA as a backend.
I have a hard time believing every Ardour user/dev would be putting up with a latency that high when simply going straight through ALSA would be that much better.
Note that the buffer settings I mentioned were for the routing under discussion: Pd and Pulseaudio through JACK, and playing a Youtube video together with Pd audio.
Ah, I see.
This is more demanding than just Pd, so I'm
not surprised that it can't be done with shorter JACK buffer. It's
already shorter than QjackCtl's default (2*1024). I don't think there's something wrong with my audio setup (but the laptop specs are modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's 'no-latency' statement to which you referred is weird. This article is more practical:
I don't see any conflict between that and what the JACK site says.
For my own laptop, Pd->ALSA works without dropouts at 5ms and Pd->JACK (->ALSA) at 5.8ms. They are set differently: setting ALSA in Pd requires an integer, and JACK has power or two frames/period and integer periods/buffer. So unfortunately there's no way to set JACK to exactly 5ms for comparison (and setting very small frames/period with many periods/buffer creates a stream of xruns even with latency > 8ms). Of course these are just the latencies in the settings-- I haven't done the actual measurements yet.
Also the statement on the jack_latency_tests link you gave that says <10ms latency on GNU/Linux systems requires a real-time kernel requires clarification. If someone wants reliable <10ms latency and isn't getting it, the very first thing to do is make sure that _nothing_ unnecessary is running (or scheduled to run) on the machine. There may be no need to install another kernel if it's the stupid Gnome indexer junk whirring in the background that's causing xruns. Or one of the other 30+ programs that are part of a system that seems perfectly happy to take 10+ seconds to load the desktop environment after the user logs in. Without taking that into consideration (especially as desktop environments that ship with the popular distros get more and more complex) realtime kernel is useless.
Also in my own tests (only with a single laptop) the realtime kernel provides more predictable cpu usage. If a test patch averages 40% cpu, then under the rt kernel it may be +/- 1%, whereas without rt kernel it may be +/- 6%. But I'm not able to set much lower latency in JACK with rt-kernel than I am with stock kernel with rt priorities. Is this the experience of others?
I'm curious what measured roundtrip latency through Pd you can get on your system when playing an internet video simultaneously, Jonathan?
Unfortunately it will have to be using a vlc-jack backend for the internet video-- not Pulse, because PulseAudio+JACK is being screwy on my machine atm.
[...]
So I suppose if a large portion of (GNU/Linux) Pd users don't need to get low latency at all, then it's beneficial to have a default audio backend that works like everything else in
their distro. However, if
getting low latency is a common goal then it's very important to lay out some instructions for how best to set up JACK to get reliable low-latency performance.
I agree. And at least these numbers are nowhere near the despicable latencies on 10-foot user interfaces where the user may have to wait up to five seconds just to know that the batteries in the remote aren't dead.
But maybe Pd just needs to go in the other direction, so latency is at minimum a couple of weeks. Is the audio that you patched at the beginning of the month worth listening to at the end of it? Think of it as a self spam filter. :)
Of course both can be done at the same time if there's enough interest. (Personally, I want to give the latter priority since it's way harder to get reliable low-latency setup than it is to get Pd to produce sound in the first place.)
Even if someone develops pulseaudio support for Pd today, it will take a while before it's in a release. Testing and documenting other mixing setups is a good idea anyway.
I agree and will try those latency tests when I get a chance.
-Jonathan
Katja