________________________________ From: katja katjavetter@gmail.com To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pddev pd-dev@iem.at Sent: Monday, June 3, 2013 7:09 AM Subject: Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2013-06-02 08:51, Jonathan Wilkes
wrote:
Of course these are just the latencies in the settings-- I haven't done the actual measurements
yet.
it would be interesting to have actual measurements. everything else is wild speculation.
Right. I would propose the following measurement protocol:
(setup/usecase A: Pd only through ALSA)
- In Pd using ALSA backend, run sine test signal in 'Media > Test
Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread.
Ok, I just need a loopback cord.
(I tried using [r~ foo]---[s~ foo] but when I drag the containing patch to move it down toward my physical connectors on the laptop, it goes outside the screen area and I can't tell whether it's lined up correctly with them. I think the problem is that my screen only bends down 45 degrees, so the patch doesn't end up on the same plane as the physical inputs. Also the wire in Pd is too far to the left so I probably can't even shove the objects far enough into the cavity to get them to connect without breaking the connection.)
(setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVI&feature=youtu.be 6.
For this combination, get the lowest nominal latency in Jack such
that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd.
In all serious now... :)
Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the "JACK adds no latency" statement and comparing additionally with just Pd running through JACK will simplify that.
Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK.
Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Regardless, we should all be using the same plugin for the comparison. (Or maybe just the same network stream through VLC, one using JACK backend and the other using the Pulse one.)
My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel:
- setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency
- setup/usecase B:
15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer
in JACK, 49.3 ms measured rountrip latency through Pd
RFC: for the Pd preferences dialog, I think the "delay" entry box should be either disabled or replaced with a label that says "set with JACK" when the JACK api is chosen. On my system setting the delay from within Pd has no impact-- you can even set it to zero!
-Jonathan