________________________________ From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Wednesday, May 29, 2013 4:00 PM Subject: Re: [PD-dev] jack dbus?
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