[PD-dev] jack dbus?

Roman Haefeli reduzent at gmail.com
Wed Jun 5 14:16:31 CEST 2013


On Mon, 2013-06-03 at 13:09 +0200, katja wrote:
> On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig <zmoelnig at 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.
> 
> (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.
> 
> 8. Report nominal + measured latencies for setup A and B, together
> with relevant hardware and system info.
> 
> 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


My results forIntel Core 2 Duo T8300 2.4GHz, Ubuntu 12.04 i386
(3.2.0-44-lowlatency-pae)

HDA Intel
---------
- usecase A: blocksize 128 in Pd, measured roundtrip 10ms
- usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms


HDSP RPM with cardbus
---------------------
- usecase A: blocksize 128 in Pd, measured roundtrip 10ms
- usecase B: 5.9ms (2frames, 128fr/period), measured roundtrip 14.9ms


Some notes:
Whether pulse server was connected to jackd didn't have any influence at
all on the best working jackd settings. Either I could start jackd or
not. When jackd was running, I didn't get any drop-outs, with or without
pulse connected as client. The buffer(ms) setting in Pd doesn't have any
influence on the effective latency on my box, with both cards. That is
why I reported only the blocksize, which seems the only parameter to
have any effect on latency. With Pd connected to jackd, even blocksize
doesn't change anything.

Unfortunately, my expensive soundcard does not perform any better than
the built-in, regarding latency. It seems this is a regression in the
alsa from my Ubuntu version. I remember I was able to set a lower value
for frames/period, 32 and 64 have been also working in previous versions
of Ubuntu, with the same laptop and the same HDSP card.

Nice latency measurement patch, btw. There is one smallish issue with
it. When testing low latency setups, the latency patch itself causes
drop-outs because of the 1-10000 loop executed in zero logical time.

Roman







More information about the Pd-dev mailing list