Hi, I have a question about latency that is added when using EQ-APO (editor.exe) and various plugins. So for now I have about 200-250ms latency. What I would like to know is if this will improve (reduce latency) with better hardware? (CPU etc.) Or is this a fixed value that doesn't scale with performance?
Thank you
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AFAIK, the latency shown by EAPO does not relate to processing time, but to latency in signal terms, i.e. the time it takes (in samples, not in seconds) for an impulse at the filter input to show up at the filter output. In other words it is purely determined by what your filters are doing, not by how fast they run.
For example, if you add a delay filter that delays the audio by 100 ms, then EAPO will show a latency of 100 ms, even though the filter itself runs in <1 ms. Obviously, better hardware will not reduce the delay.
Filter processing time is an all-or-nothing proposition: the filters have to be able to process the audio in real-time, i.e. a 10 ms buffer has to be processed in less than 10 ms, otherwise you'll end up with glitchy audio. As long as buffers are processed in time, faster processing changes nothing as far as the audio is concerned, it just results in less CPU usage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm... as Configuration Editor just writes the updated configuration file(s), delay depends on how much and what kind of stuff you have there in editor side to write to the file(s).
If you hand code a simple 1st order LPF in config.txt it would add latency (seen in editor's metering) quite a bit because of extra lines of code (parsing these code lines and executing all coded commands would add latency too but, I think it's not related to the reported latency value because of parsing/calculations would be done only once).
I have not looked what this latency value seen in editor actually means ... is it just calculated/approximated file processing time (to get analyzer panel fully updated)? (IIRC), in log file, you can see how long time it took by equalizerapo.dll to read/process the config.txt and its included files.
If it is question on file processing time then (it's HW question too then) a faster drive would drop the latency a bit (maybe a RAM-drive would be even faster).
Last edit: Juha 2024-08-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You seem to be referring to what the configurator calls "init time", which is indeed the time it takes to load the filters, not run them. Init time matters in terms of how long it takes to initialize an audio stream, but once the audio stream has been initialized it has no effect on latency or anything else.
I have not looked what this latency value seen in editor actually means ... is it just calculated/approximated file processing time
It is not processing time. It is an estimate of the delay introduced by the filter itself.
Here is the code that calculates the latency. What this basically does is it plays some signal through the filter, and then it looks at the output of the filter and determines the position of the first sample in the output that is not silence (specifically, sample value >1e-5). The code doesn't care how long it took for the filter to run - all it cares about is how much silence the filter output before the first "real" sample appeared.
So, if the EAPO Configurator shows a "latency" of "100 ms", then this means that if you send a signal to the filter, the filter will output 100 ms of silence before it will start outputting a real signal. It does not mean the filter took 100 ms to run (which wouldn't work, anyway - APOs have a 10 ms time budget).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Note that the latency of the audio engine (EqualizerAPO.dll) is the audio latency. The Configuration Editor (editor.exe) doesn't introduce any audio latency as it's only saving Equalizer APO commands to files which are then read by the audio engine. However, there is the CPU usage of the editor which is especially high when using lots of plugins. Remember, the plugins are also loaded by EqualizerAPO.dll which may cause high audio latency when using many plugins. So in order to reduce CPU usage just close the editor. That's the easiest fix. In order to reduce the audio latency just get better hardware or crank up the existing hardware in the BIOS or so.
The above text answers your questions but to be specific, to lessen the CPU usage of the editor get better hardware or speed up your existing hardware. And to reduce the audio latency do the same. When the audio engine is running faster the audio stream is faster manipulated causing less audio latency and also CPU usage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When the audio engine is running faster the audio stream is faster manipulated causing less audio latency
No. That's not how this works.
The internal buffer size of the Windows Audio Engine is 10 ms. Since this is real-time processing, this means the Windows Audio Engine (including any APOs) has a total "time budget" of 10 ms to process a 10 ms buffer (in reality slightly less because there is also some overhead downstream of the engine).
This 10 ms budget is fixed - just because the buffer was processed in less than 10 ms does not mean it's going to be delivered earlier to the hardware. The pace of buffer delivery is ultimately controlled by the audio clock, not by how fast buffers can be produced.
Faster processing does not result in lower latency. However it does result in (1) less CPU usage and (2) lower probability of glitches because there is more "safety margin" within the processing time budget.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, but everything isn't in real time. Streaming like YouTube, Netflix, Spotify and also audio/video apps use buffering which is all needed for preventing audio/video stutter, syncing the audio and video, in DAWs syncing all audio tracks/streams, etc. etc. As long as there isn't a noticeable delay/latency everything is fine. Besides, in normal circumstance after clicking on the play button the initial audio/video delay isn't even noticed by the user unless it becomes too large like 1 second or more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The OP was mentioning latencies in the order of 200-250 ms. This is very high latency that would be very noticeable (and very annoying) in most use cases besides music playback. This amount of A/V desync is definitely unacceptable for any kind of video playback, unless the user manually compensates in the other direction using video player controls (assuming it provides such controls).
The OP should ideally try to bring this down to 50 ms or less if he wants to support general use cases like video playback or gaming. To do this the OP would have to use different filters or different filter parameters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I have a question about latency that is added when using EQ-APO (editor.exe) and various plugins. So for now I have about 200-250ms latency. What I would like to know is if this will improve (reduce latency) with better hardware? (CPU etc.) Or is this a fixed value that doesn't scale with performance?
Thank you
AFAIK, the latency shown by EAPO does not relate to processing time, but to latency in signal terms, i.e. the time it takes (in samples, not in seconds) for an impulse at the filter input to show up at the filter output. In other words it is purely determined by what your filters are doing, not by how fast they run.
For example, if you add a delay filter that delays the audio by 100 ms, then EAPO will show a latency of 100 ms, even though the filter itself runs in <1 ms. Obviously, better hardware will not reduce the delay.
Filter processing time is an all-or-nothing proposition: the filters have to be able to process the audio in real-time, i.e. a 10 ms buffer has to be processed in less than 10 ms, otherwise you'll end up with glitchy audio. As long as buffers are processed in time, faster processing changes nothing as far as the audio is concerned, it just results in less CPU usage.
Hmm... as Configuration Editor just writes the updated configuration file(s), delay depends on how much and what kind of stuff you have there in editor side to write to the file(s).
If you hand code a simple 1st order LPF in config.txt it would add latency (seen in editor's metering) quite a bit because of extra lines of code (parsing these code lines and executing all coded commands would add latency too but, I think it's not related to the reported latency value because of parsing/calculations would be done only once).
I have not looked what this latency value seen in editor actually means ... is it just calculated/approximated file processing time (to get analyzer panel fully updated)? (IIRC), in log file, you can see how long time it took by equalizerapo.dll to read/process the config.txt and its included files.
If it is question on file processing time then (it's HW question too then) a faster drive would drop the latency a bit (maybe a RAM-drive would be even faster).
Last edit: Juha 2024-08-07
You seem to be referring to what the configurator calls "init time", which is indeed the time it takes to load the filters, not run them. Init time matters in terms of how long it takes to initialize an audio stream, but once the audio stream has been initialized it has no effect on latency or anything else.
It is not processing time. It is an estimate of the delay introduced by the filter itself.
Here is the code that calculates the latency. What this basically does is it plays some signal through the filter, and then it looks at the output of the filter and determines the position of the first sample in the output that is not silence (specifically, sample value >1e-5). The code doesn't care how long it took for the filter to run - all it cares about is how much silence the filter output before the first "real" sample appeared.
So, if the EAPO Configurator shows a "latency" of "100 ms", then this means that if you send a signal to the filter, the filter will output 100 ms of silence before it will start outputting a real signal. It does not mean the filter took 100 ms to run (which wouldn't work, anyway - APOs have a 10 ms time budget).
Note that the latency of the audio engine (EqualizerAPO.dll) is the audio latency. The Configuration Editor (editor.exe) doesn't introduce any audio latency as it's only saving Equalizer APO commands to files which are then read by the audio engine. However, there is the CPU usage of the editor which is especially high when using lots of plugins. Remember, the plugins are also loaded by EqualizerAPO.dll which may cause high audio latency when using many plugins. So in order to reduce CPU usage just close the editor. That's the easiest fix. In order to reduce the audio latency just get better hardware or crank up the existing hardware in the BIOS or so.
The above text answers your questions but to be specific, to lessen the CPU usage of the editor get better hardware or speed up your existing hardware. And to reduce the audio latency do the same. When the audio engine is running faster the audio stream is faster manipulated causing less audio latency and also CPU usage.
No. That's not how this works.
The internal buffer size of the Windows Audio Engine is 10 ms. Since this is real-time processing, this means the Windows Audio Engine (including any APOs) has a total "time budget" of 10 ms to process a 10 ms buffer (in reality slightly less because there is also some overhead downstream of the engine).
This 10 ms budget is fixed - just because the buffer was processed in less than 10 ms does not mean it's going to be delivered earlier to the hardware. The pace of buffer delivery is ultimately controlled by the audio clock, not by how fast buffers can be produced.
Faster processing does not result in lower latency. However it does result in (1) less CPU usage and (2) lower probability of glitches because there is more "safety margin" within the processing time budget.
Basically that's what I'm referring to. But it's highly technical to cover by a simple explanation so I took the shortcut.
I didn't know that. It seems a bit short when using many complex plugins although computers are fast nowadays.
That's obvious but try explaining all this to someone who isn't a techie.
okay thank you
so even with a computer from the future this will never be "real-time"
No, but everything isn't in real time. Streaming like YouTube, Netflix, Spotify and also audio/video apps use buffering which is all needed for preventing audio/video stutter, syncing the audio and video, in DAWs syncing all audio tracks/streams, etc. etc. As long as there isn't a noticeable delay/latency everything is fine. Besides, in normal circumstance after clicking on the play button the initial audio/video delay isn't even noticed by the user unless it becomes too large like 1 second or more.
The OP was mentioning latencies in the order of 200-250 ms. This is very high latency that would be very noticeable (and very annoying) in most use cases besides music playback. This amount of A/V desync is definitely unacceptable for any kind of video playback, unless the user manually compensates in the other direction using video player controls (assuming it provides such controls).
The OP should ideally try to bring this down to 50 ms or less if he wants to support general use cases like video playback or gaming. To do this the OP would have to use different filters or different filter parameters.
Videos are no problem, you can adjust the delay in the software but video games are "real-time"
we posted at the same time xD
and thats true at 200ms delay the lipsync is very distracting, thats why I switched to watch youtube via MPV
Last edit: Peter Dirk 2024-08-07