[PD-dev] jack dbus?

[katja]

On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes <jancsika at 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