On Wed, Jun 5, 2013 at 2:16 PM, Roman Haefeli reduzent@gmail.com wrote:
[...]
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.
(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.
- 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.
Just to make sure: did you also play the internet video, and get uncompromised quality for both audio signals with those settings?
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.
This is weird, eh? I guess the Media > Audio Settings > Delay(msec) sets Pd's buffer size (rounded or truncated to an integer number of blocks), when it's using ALSA. Anyway this setting normally influences measured latency in a linear fashion. When Pd goes through JACK instead, it seems that Pd's buffer size setting is irrelevant because JACK's buffer is forwarded to Pd.
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.
That is not elegant indeed, even though the loop comes after the data is recorded. I could not find an alternative for the loop, using vanilla objects. If it could be broken in parts, your [nbuntil] solution could help.
Katja