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. I guess the absolute latency could be lower on faster hardware, but my point was to compare the different routings while keeping other conditions equal.
By the way this does of course not say anything about latency in Pulseaudio. Maybe there is a way to test that with a 'pulsified' application, for example Audacity.
That would be interesting to see.
By way of test, in Audacity I've set recording and playback device to pulse, and recorded a click at time zero from track 1 to track 2 via loopback. Buffer size and latency compensation were both set to 100 ms so they should compensate each other. The recorded impulse appears at around 0.058 seconds. If I've done it right, this would point to 58 ms total roundtrip latency. In a real time application like Pd you could not compensate for latency, so Pd's own buffer length should probably be added to the figure, making some 70 ms as a minimum.
It seems to me that direct PulseAudio support for Pd would be interesting for ease of use, especially important for Pd/Linux beginners. Long latency is annoying, but at least less confusing than having no audio at all from some applications. However, it should be noted that Pulseaudio's mixer does not by definition provide controls for all (parts of) hardware devices. In some cases, it silently switches an input or output, without presenting the corresponding button on the mixer GUI. In such a case, only an ALSA mixer gives control over the hardware, and pulseaudio must be killed to return control to the ALSA mixer. So, Pulseaudio can make things very confusing too. But that goes beyond the influence of Pd.
Katja