<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div id="yiv4072056919"><div><div style="color:#000;background-color:#fff;font-family:arial, helvetica, sans-serif;font-size:12pt;"><div id="yiv4072056919yui_3_7_2_32_1370130265265_56"><span></span></div><div class="yiv4072056919yui_3_7_2_32_1370130265265_60" id="yiv4072056919yui_3_7_2_32_1370130265265_61" style="font-family:arial, helvetica, sans-serif;font-size:12pt;"> <div id="yiv4072056919yui_3_7_2_32_1370130265265_80" class="yiv4072056919yui_3_7_2_32_1370130265265_64" style="font-family:times new roman, new york, times, serif;font-size:12pt;"> <div id="yiv4072056919yui_3_7_2_32_1370130265265_79" dir="ltr"> <hr size="1"> <font id="yiv4072056919yui_3_7_2_32_1370130265265_78" face="Arial" size="2"> <b id="yiv4072056919yui_3_7_2_32_1370130265265_77"><span id="yiv4072056919yui_3_7_2_32_1370130265265_76"
style="font-weight:bold;">From:</span></b> katja <katjavetter@gmail.com><br> <b id="yiv4072056919yui_3_7_2_32_1370130265265_93"><span id="yiv4072056919yui_3_7_2_32_1370130265265_92" style="font-weight:bold;">To:</span></b> Jonathan Wilkes <jancsika@yahoo.com> <br><b id="yiv4072056919yui_3_7_2_32_1370130265265_97"><span id="yiv4072056919yui_3_7_2_32_1370130265265_96" style="font-weight:bold;">Cc:</span></b> "pd-dev@iem.at" <pd-dev@iem.at> <br> <b id="yiv4072056919yui_3_7_2_32_1370130265265_101"><span id="yiv4072056919yui_3_7_2_32_1370130265265_100" style="font-weight:bold;">Sent:</span></b> Saturday, June 1, 2013 2:39 PM<br> <b id="yiv4072056919yui_3_7_2_32_1370130265265_105"><span id="yiv4072056919yui_3_7_2_32_1370130265265_104" style="font-weight:bold;">Subject:</span></b> Re: [PD-dev] jack dbus?<br> </font> </div> <div id="yiv4072056919yui_3_7_2_32_1370130265265_108" class="yiv4072056919y_msg_container"><br>>> On Wed, May 29,
2013 at 7:32 PM, Jonathan Wilkes <<a rel="nofollow" ymailto="mailto:jancsika@yahoo.com" target="_blank" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>> wrote:<br>>><br>>>>> There's no other combination of frames/period and period/buffer you<br>>>>> can use to get ca. 17-20ms latency without dropouts?<br>>><br>>>>Not on the hardware I'm
using.<br>>><br>>> Any ideas on what is causing the discrepancy? It has to be either a<br>>> bug in JACK/Pd/OS, or some configuration detail (e.g., JACK isn't<br>>> in realtime mode or something more subtle). I wouldn't think it has<br>>> to do with your specific audio device as JACK uses ALSA as a<br>>> backend.<br>>><br>>> I have a hard time believing every Ardour user/dev would be putting up with<br>>> a latency that high when simply going straight through ALSA would be<br>>> that much better.<br><br>>Note that the buffer settings I mentioned were for the routing under<br>>discussion: Pd and Pulseaudio through JACK, and playing a Youtube<br>>video together with Pd audio.<br><br>Ah, I see.<br><br>> This is more demanding than just Pd, so<br>>I'm
not surprised that it can't be done with shorter JACK buffer. It's<br>>already shorter than QjackCtl's default (2*1024). I don't think<br>>there's something wrong with my audio setup (but the laptop specs are<br>>modest with 1 GHz core2duo, no preemptive kernel). Jackaudio.org's<br>>'no-latency' statement to which you referred is weird. This article is<br>>more practical:<br><br><a rel="nofollow" id="yiv4072056919yui_3_7_2_32_1370130265265_138" target="_blank" href="http://apps.linuxaudio.org/wiki/jack_latency_tests">>http://apps.linuxaudio.org/wiki/jack_latency_tests</a><br><br>I don't see any conflict between that and what the JACK site says.<br><br>For my own laptop, Pd->ALSA works without dropouts at 5ms<br>and Pd->JACK (->ALSA) at 5.8ms. They are set differently: setting<br>ALSA in Pd requires an integer, and JACK has power or two<br>frames/period and integer periods/buffer. So unfortunately there's<br>no way
to set JACK to exactly 5ms for comparison (and setting<br>very small frames/period with many periods/buffer creates a<br>stream of xruns even with latency > 8ms). Of course these are<br>just the latencies in the settings-- I haven't done the actual<br>measurements yet.<br><br>Also the statement on the jack_latency_tests link you gave that says<br><10ms latency on GNU/Linux systems requires a real-time kernel<br>requires clarification. If someone wants reliable <10ms latency and<br>isn't getting it, the very first thing to do is make sure that _nothing_<br>unnecessary is running (or scheduled to run) on the machine. There<br>may be no need to install another kernel if it's the stupid Gnome<br>indexer junk whirring in the background that's causing xruns. Or one<br>of the other 30+ programs that are part of a system that seems perfectly<br>happy to take 10+ seconds to load the desktop environment after the<br>user logs
in. Without taking that into consideration (especially as<br>desktop environments that ship with the popular distros get more and<br>more complex) realtime kernel is useless.<br><br>Also in my own tests (only with a single laptop) the realtime kernel provides<br>more predictable cpu usage. If a test patch averages 40% cpu, then under<br>the rt kernel it may be +/- 1%, whereas without rt kernel it may be +/- 6%.<br>But I'm not able to set much lower latency in JACK with rt-kernel than I<br>am with stock kernel with rt priorities. Is this the experience of others?<br><br>>I'm curious what measured roundtrip latency through Pd you can get on<br>>your system when playing an internet video simultaneously, Jonathan?<br><br>Unfortunately it will have to be using a vlc-jack backend for the<br>internet video-- not Pulse, because PulseAudio+JACK is being<br>screwy on my machine atm.<br><br>>[...]<br><br>>> So I suppose if a large
portion of (GNU/Linux) Pd users don't need to<br>>> get low latency at all, then it's beneficial to have a default audio<br>>> backend that works like everything else in
their distro. However, if<br>>> getting low latency is a common goal then it's very important to lay out<br>>> some instructions for how best to set up JACK to get reliable low-latency<br>>> performance.<br><br>I agree. And at least these numbers are nowhere near the despicable<br>latencies on 10-foot user interfaces where the user may have to wait up<br>to five seconds just to know that the batteries in the remote aren't dead.<br><br>But maybe Pd just needs to go in the other direction, so latency is at<br>minimum a couple of weeks. Is the audio that you patched at the<br>beginning of the month worth listening to at the end of it? Think of<br>it as a self spam filter. :)<br><br>>><br>>> Of course both can be done at the same time if there's enough interest.<br>>> (Personally, I want to give the latter priority since it's way<br>>> harder to get reliable low-latency setup than it is to
get Pd to produce<br>>> sound in the first place.)<br><br>>Even if someone develops pulseaudio support for Pd today, it will take<br>>a while before it's in a release. Testing and documenting other mixing<br>>setups is a good idea anyway.<br><br>I agree and will try those latency tests when I get a chance.<br><br>-Jonathan<br><br>Katja<br><br><br></div> </div> </div> </div></div></div></div></body></html>