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

>Note that the buffer settings I mentioned were for the routing under
>discussion: Pd and Pulseaudio through JACK, and playing a Youtube
>video together with Pd audio.

Ah, I see.

> This is more demanding than just Pd, so
>I'm not surprised that it can't be done with shorter JACK buffer. It's
>already shorter than QjackCtl's default (2*1024). I don't think
>there's something wrong with my audio setup (but the laptop specs are
>modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's
>'no-latency' statement to which you referred is weird. This article is
>more practical:

>http://apps.linuxaudio.org/wiki/jack_latency_tests

I don't see any conflict between that and what the JACK site says.

For my own laptop, Pd->ALSA works without dropouts at 5ms
and Pd->JACK (->ALSA) at 5.8ms.  They are set differently: setting
ALSA in Pd requires an integer, and JACK has power or two
frames/period and integer periods/buffer.  So unfortunately there's
no way to set JACK to exactly 5ms for comparison (and setting
very small frames/period with many periods/buffer creates a
stream of xruns even with latency > 8ms).  Of course these are
just the latencies in the settings-- I haven't done the actual
measurements yet.

Also the statement on the jack_latency_tests link you gave that says
<10ms latency on GNU/Linux systems requires a real-time kernel
requires clarification.  If someone wants reliable <10ms latency and
isn't getting it, the very first thing to do is make sure that _nothing_
unnecessary is running (or scheduled to run) on the machine.  There
may be no need to install another kernel if it's the stupid Gnome
indexer junk whirring in the background that's causing xruns.  Or one
of the other 30+ programs that are part of a system that seems perfectly
happy to take 10+ seconds to load the desktop environment after the
user logs in.  Without taking that into consideration (especially as
desktop environments that ship with the popular distros get more and
more complex) realtime kernel is useless.

Also in my own tests (only with a single laptop) the realtime kernel provides
more predictable cpu usage.  If a test patch averages 40% cpu, then under
the rt kernel it may be +/- 1%, whereas without rt kernel it may be +/- 6%.
But I'm not able to set much lower latency in JACK with rt-kernel than I
am with stock kernel with rt priorities.  Is this the experience of others?

>I'm curious what measured roundtrip latency through Pd you can get on
>your system when playing an internet video simultaneously, Jonathan?

Unfortunately it will have to be using a vlc-jack backend for the
internet video-- not Pulse, because PulseAudio+JACK is being
screwy on my machine atm.

>[...]

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

I agree.  And at least these numbers are nowhere near the despicable
latencies on 10-foot user interfaces where the user may have to wait up
to five seconds just to know that the batteries in the remote aren't dead.

But maybe Pd just needs to go in the other direction, so latency is at
minimum a couple of weeks.  Is the audio that you patched at the
beginning of the month worth listening to at the end of it?  Think of
it as a self spam filter. :)

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

>Even if someone develops pulseaudio support for Pd today, it will take
>a while before it's in a release. Testing and documenting other mixing
>setups is a good idea anyway.

I agree and will try those latency tests when I get a chance.

-Jonathan

Katja