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.

Any ideas on what is causing the discrepancy?  It has to be either a
bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't
in realtime mode or something more subtle).  I wouldn't think it has
to do with your specific audio device as JACK uses ALSA as a
backend.

I have a hard time believing every Ardour user/dev would be putting up with
a latency that high when simply going straight through ALSA would be
that much better.

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

If your numbers are right, then that would be large enough to disqualify
use-case #3 that I gave: guy screwing around with guitar processing, possibly
live.  The latency is too high for that.

I think this is the case for the default setting on Windows.  At least the
last time I did audio on Windows the default latency in Pd's setting
was something like 100ms.  It means that if/when the user hits upon
a patch where lower latency matters there is a whole host of issues
they must confront.

So I suppose if a large portion of (GNU/Linux) Pd users don't need to
get low latency at all, then it's beneficial to have a default audio
backend that works like everything else in their distro.  However, if
getting low latency is a common goal then it's very important to lay out
some instructions for how best to set up JACK to get reliable low-latency
performance.

Of course both can be done at the same time if there's enough interest.
(Personally, I want to give the latter priority since it's way
harder to get reliable low-latency setup than it is to get Pd to produce
sound in the first place.)

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

Actually, I _think_ Pd's ALSA backend and interface complicates things
another way.  The user is presented with a series of device names after they
choose the ALSA api, but Pd-gui forwards device numbers to Pd,
as well as saving device numbers in the preferences file.  If you choose
that usb microphone that you just plugged in by name in the dropdown
list and save your preferences, you're not guaranteed to get it back
the next time you run Pd because the device number might be assigned
to something else.  (Simple example: you're using a usb audio interface
and a usb microphone.)

It's tangential to the issue you describe, but in both cases Hal isn't opening
the pod bay door. :)

-Jonathan