- This topic is empty.
August 3, 2018 at 4:02 pm #114877cauldronParticipant
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?
August 3, 2018 at 4:23 pm #149861tlongabaughModeratorEventide Staff
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.
*EDIT: revised number of samples to be correct for 176.4k and 192k.
August 3, 2018 at 9:12 pm #149867cauldronParticipant
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).
26896.000 frames 140.083 ms
16384.000 frames 85.333 ms
26896.000 frames 152.472 ms
16384.000 frames 92.880 ms
21776.000 frames 226.833 ms
16384.000 frames 170.667 ms
88.2kHz ***5392***Show More...Show Less...
21776.000 frames 246.893 ms
16384.000 frames 185.760 ms
19216.000 frames 400.333 ms
16384.000 frames 341.333 ms
19216.000 frames 435.737 ms
16384.000 frames 371.519 ms
August 6, 2018 at 3:56 pm #149875tlongabaughModeratorEventide Staff
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".
March 31, 2021 at 12:23 pm #157554cauldronParticipantIt 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.7ms176400f, 10512s, 59.6ms96000f, 5392s, 56.1msShow More...Show Less...88200f, 5392s, 61.1ms48000f, 2832s, 59.0ms44100f, 2832s, 64.2ms
- You must be logged in to reply to this topic.