Etienne Dechamps

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...

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...

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...

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...

I'm under the impression that the GraphicEQ command of Equalizer APO uses convolution Sure. I was just clarifying that one can use convolution without using GraphicEQ, by supplying their own filters (impulse responses). That begs the question of why using such elaborate filters. A bit overkill? Long filters are necessary for high accuracy in the bass region. Clever calibration packages will combine IIR filters in low frequencies (for computational efficiency) with FIR filters in high frequencies...

I don't think Equalizer APO can be multithreading. Certainly a channel per core isn't possible. There is nothing stopping an APO from creating its own internal threads and then distributing work over them. EAPO doesn't do that, though. Of course convolution (is this FIR?) or graphic eq as Equalizer APO calls it Convolution/FIR and "graphic eq" aren't the same thing. Convolution filters can be quite expensive if the filter is long (many taps). For example, DRC-FIR generates huge 65k-tap filters by...

The "steepness" of a Butterworth or Linkwitz-Riley filter is determined by its order value. In case of Peace, the order is entered in the Q value field (below a slider). There is some confusion here. "Order" and "Q value" are not the same thing. Q is a tradeoff between stopband attenuation and passband ripple. Filter order is a tradeoff between computational efficiency and filter sharpness. These are two completely separate parameters that are mostly orthogonal to each other.

WOA (windows on arm) should be able to use Prism to execute any x64 applications Equalizer APO is a special case because it is not an application - it is a plug-in DLL that gets loaded into a Windows system process (audiodg.exe). It could be that audiodg.exe is built as ARM64, not ARM64EC, which would mean it can't load x64 code. It's either that, or a bug in the Equalizer APO installer (perhaps it is confused about which architecture it's running on). I don't have a Windows ARM machine so I can't...