Hi,
for a project involving controlled and tuned feedback through the Audio Interface, we need very low latency (~ 9-10 ms roundtrip through the analog ins/outs) for it to work properly. We did some tests using OSX and linux based systems with different audio interfaces.
On OSX I can get down to 16 ms with pd (44.1 kHz sr); using Max/MSP we can get below 10ms with a vector size of 32.
On Linux the lowest I can get with pd is 29.33 ms with 48k samplerate (this is using alsa; jack is ~34 ms).
jack_delay reports a 9.6 ms roundtrip delay through the analog outputs with a vector size of 64, so it is not the driver and in principle should be possible to get a lower latency in linux. I don't know if jack_delay is implemented with additional i/o buffers but even if pd adds an extra period in both directions that should be well below 30ms (64 samples are 1.33 ms at 48k). The added 20ms in comparison to jack_delay appear quite large to me.
I even tried to compile pd with a lower blocksize (I changed DEFDACBLKSIZE in s_stuff.h and DEFSENDVS in d_global.c and can get down to a vectorsize of 32 without distortion at the audio interface), but that doesn't change the i/o latency at all. I didn't yet study the alsa/jack related code.
Can anyone shed a light on this? It'd be much nicer to use pd for this than writing a dedicated app doing all the dsp (or using Max/MSP on OSX :-(
-- Orm
Hi,
I found it: The delay setting in the audio settings is the culprit: It was set at 25 ms and setting
If you want to reduce latency even more, try to enable "callbacks" in the audio settings (or start Pd with the "-callback" option). Generally, this is not recommend, unless you really need the lowest possible latency.
I even tried to compile pd with a lower blocksize
To anyone reading: don't try this at home!
Christof
On 10.05.2023 19:04, Orm Finnendahl wrote:
Hi,
for a project involving controlled and tuned feedback through the Audio Interface, we need very low latency (~ 9-10 ms roundtrip through the analog ins/outs) for it to work properly. We did some tests using OSX and linux based systems with different audio interfaces.
On OSX I can get down to 16 ms with pd (44.1 kHz sr); using Max/MSP we can get below 10ms with a vector size of 32.
On Linux the lowest I can get with pd is 29.33 ms with 48k samplerate (this is using alsa; jack is ~34 ms).
jack_delay reports a 9.6 ms roundtrip delay through the analog outputs with a vector size of 64, so it is not the driver and in principle should be possible to get a lower latency in linux. I don't know if jack_delay is implemented with additional i/o buffers but even if pd adds an extra period in both directions that should be well below 30ms (64 samples are 1.33 ms at 48k). The added 20ms in comparison to jack_delay appear quite large to me.
I even tried to compile pd with a lower blocksize (I changed DEFDACBLKSIZE in s_stuff.h and DEFSENDVS in d_global.c and can get down to a vectorsize of 32 without distortion at the audio interface), but that doesn't change the i/o latency at all. I didn't yet study the alsa/jack related code.
Can anyone shed a light on this? It'd be much nicer to use pd for this than writing a dedicated app doing all the dsp (or using Max/MSP on OSX :-(
-- Orm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2023-05-10 at 19:04 +0200, Orm Finnendahl wrote:
jack_delay reports a 9.6 ms roundtrip delay through the analog outputs with a vector size of 64, so it is not the driver and in principle should be possible to get a lower latency in linux.
When using -callback (as Christof already suggested), you should get exactly the same latency as measured by jack_delay. And in my experience, that is indeed the case.
While using the callback scheduler, Pd used to hang after switching audio backends. This is fixed in the Christof's scheduler_fix PR¹. I hope this gets merged soonish.
Roman
Orm, you might wanna see if running your interface in 96kHz will halve the latency further. best, P