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)
>1. 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