<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span></span></div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> katja <katjavetter@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> Jonathan Wilkes <jancsika@yahoo.com> <br><b><span style="font-weight: bold;">Cc:</span></b> "pd-dev@iem.at" <pd-dev@iem.at> <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, May 29, 2013 4:00 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [PD-dev] jack dbus?<br> </font> </div> <div class="y_msg_container"><br>On Wed, May 29, 2013 at 7:32 PM, Jonathan Wilkes <<a ymailto="mailto:jancsika@yahoo.com"
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>>>>By the way this does of course not say anything about latency in<br>>>>Pulseaudio. Maybe there is a way to test that with a 'pulsified'<br>>>>application, for example
Audacity.<br>>><br>>> That would be interesting to see.<br><br>>By way of test, in Audacity I've set recording and playback device to<br>>pulse, and recorded a click at time zero from track 1 to track 2 via<br>>loopback. Buffer size and latency compensation were both set to 100 ms<br>>so they should compensate each other. The recorded impulse appears at<br>>around 0.058 seconds. If I've done it right, this would point to 58 ms<br>>total roundtrip latency. In a real time application like Pd you could<br>>not compensate for latency, so Pd's own buffer length should probably<br>>be added to the figure, making some 70 ms as a minimum.<br><br>If your numbers are right, then that would be large enough to disqualify<br>use-case #3 that I gave: guy screwing around with guitar processing, possibly<br>live. The latency is too high for that.<br><br>I think this is the case for the default setting on Windows. At least
the<br>last time I did audio on Windows the default latency in Pd's setting<br>was something like 100ms. It means that if/when the user hits upon<br>a patch where lower latency matters there is a whole host of issues<br>they must confront.<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>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>>It seems to me that direct PulseAudio support for Pd would
be<br>>interesting for ease of use, especially important for Pd/Linux<br>>beginners. Long latency is annoying, but at least less confusing than<br>>having no audio at all from some applications. However, it should be<br>>noted that Pulseaudio's mixer does not by definition provide controls<br>>for all (parts of) hardware devices. In some cases, it silently<br>>switches an input or output, without presenting the corresponding<br>>button on the mixer GUI. In such a case, only an ALSA mixer gives<br>>control over the hardware, and pulseaudio must be killed to return<br>>control to the ALSA mixer. So, Pulseaudio can make things very<br>>confusing too. But that goes beyond the influence of Pd.<br><br>Actually, I _think_ Pd's ALSA backend and interface complicates things<br>another way. The user is presented with a series of device names after they<br>choose the ALSA api, but Pd-gui forwards device numbers to Pd,<br>as well
as saving device numbers in the preferences file. If you choose<br>that usb microphone that you just plugged in by name in the dropdown<br>list and save your preferences, you're not guaranteed to get it back<br>the next time you run Pd because the device number might be assigned<br>to something else. (Simple example: you're using a usb audio interface<br>and a usb microphone.)<br><br>It's tangential to the issue you describe, but in both cases Hal isn't opening<br>the pod bay door. :)<br><br>-Jonathan<br><br></div> </div> </div> </div></body></html>