How to improve the Physion latency (2832 samples!)

[cauldron]

From a series of experimental measurements it appears that Physion’s latency does not change as a number of audio samples compared to the sampling frequency. This means that at 48kHz, 96kHz or 192kHz the latency of 2832 audio samples is 59.0ms, 29.5ms or 14.7ms, respectively. Practically for a live use it is necessary to use a sampling frequency of 96kHz or higher.

Is it possible to reduce latency to one-tenth or is it a structural fact that can not be improved?

Thanks

[tlongabaugh]

Hi-

Where and how are you viewing the latency of the plugin? I can confirm here that the latency in samples changes depending on the sample rate. It should be 2832 samples for 44.1k and 48k, 5392 samples for 88.2k and 96k, and 8672 *10512 samples for 176.4k and 192k.

This does produce a noticeable delay of roughly 50ms, which of course is fine in a mixing scenario, but isn't acceptable for live use. Unfortunately, this is what is currently required for the structural split to work well. We hope to optimize this in the future.

-Tom

*EDIT: revised number of samples to be correct for 176.4k and 192k.

[cauldron]

Hi Tom,

I apologize. I have redoed the measurements and I confirm what you said except for 176.4kHz and 192kHz which are 10512 samples.

I used a buffer of 8192 samples. The round-trip time is measured (with and without the Physion plugin) using the jack_delay utility ( https://kokkinizita.linuxaudio.org/linuxaudio/downloads/jack_delay-0.4.0.tar.bz2 ). Jack Audio includes the jack_iodelay utility which is equivalent.

Latency is always constant (just over 50ms).

192kHz  ***10512***

      26896.000 frames  140.083 ms

      16384.000 frames   85.333 ms

176.4kHz ***10512***

      26896.000 frames  152.472 ms

      16384.000 frames   92.880 ms

96kHz ***5392***

      21776.000 frames  226.833 ms

      16384.000 frames  170.667 ms

88.2kHz ***5392***

      21776.000 frames  246.893 ms

      16384.000 frames  185.760 ms

48kHz  ***2832***

      19216.000 frames  400.333 ms

      16384.000 frames  341.333 ms

44.1kHz ***2832***

      19216.000 frames  435.737 ms

      16384.000 frames  371.519 ms

 

Elia

 

[tlongabaugh]

Sorry, 10512 samples is correct for 176.4k and 192k. I'll amend my original post to be correct.

Keep in mind that the buffer size you are running will also factor into the roundtrip delay. 8192 is quite a large buffer size, and will cause a noticeable delay even without any latency-causing plugins, if you are trying to play anything "live".

[cauldron]

It would be interesting if three years later it was also possible to add a lower latency version for a live context. Currently the waveform is divided into frames of ~40ms and is analyzed to find stable and/or predictable patterns ( https://www.eventideaudio.com/blog/nsanchez/introduction-structural-effects ). It could be very useful to go from 40 to 30 or 20ms and in many contexts it could be a triumph.

The current version 2.8.8 always maintains the same latency values that I repeat below (frequency, sample delay, time delay). Currently the least delay is achieved at 192kHz, -10ms compared to 44.1kHz.

192000f, 10512s, 54.7ms

176400f, 10512s, 59.6ms

  96000f,   5392s, 56.1ms

  88200f,   5392s, 61.1ms

  48000f,   2832s, 59.0ms

  44100f,   2832s, 64.2ms

 

[Author]

Posts