[PD-dev] jack dbus?

katja katjavetter at gmail.com
Sat Jun 1 20:39:07 CEST 2013


> 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.
>
> 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. 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'm curious what measured roundtrip latency through Pd you can get on
your system when playing an internet video simultaneously, Jonathan?

[...]

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

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.

Katja



More information about the Pd-dev mailing list