INTERACT FORUM
More => Old Versions => JRiver Media Center 29 for Windows => Topic started by: markf2748 on March 10, 2022, 11:27:59 am
-
New (?) in MC 29.0.109 DSP Button's Audio Path popup window:
Delay: xx ms delay from converter; yy ms from input until heard
I see xx~0.2, yy~5000, both fluctuating.
Can someone explain the meaning/significance of the values xx and yy, and are they affected by any user settable options? Or update Wiki?
-
New (?) in MC 29.0.109 DSP Button's Audio Path popup window:
Delay: xx ms delay from converter; yy ms from input until heard
I see xx~0.2, yy~5000, both fluctuating.
Can someone explain the meaning/significance of the values xx and yy, and are they affected by any user settable options? Or update Wiki?
The second number is the total delay and seems to hover around whatever your "prebuffering" setting is under options-->Audio, although it starts lower until the buffer fills. I seem to be able to change that number pretty effectively by altering the prebuffering setting.
I'm not sure exactly what the first number represents or how one might affect it. I haven't found settings that seem to affect it (yet).
-
The first number is the actual DSP latency, you can see it increase if you use eg. resampling, which increases the latency. Even more so if you use SSRC.
I get about 0.5ms without any processing (I'm not sure what that is, might be just the render buffer), 160ms with SoX 44.1 -> 48, and ~500 with SSRC 44.1 -> 48
The second number includes the audio device buffer, which is mostly important if you try to eg. sync up live sources (WDM etc), where you want to keep that low.
-
The first number is the actual DSP latency, you can see it increase if you use eg. resampling, which increases the latency. Even more so if you use SSRC.
I get about 0.5ms without any processing (I'm not sure what that is, might be just the render buffer), 160ms with SoX 44.1 -> 48, and ~500 with SSRC 44.1 -> 48
The second number includes the audio device buffer, which is mostly important if you try to eg. sync up live sources (WDM etc), where you want to keep that low.
Interesting. I tried increasing the delay by adding a delay filter in PEQ and it didn't seem to affect the first number at all. Is the first number just the resampling delay specifically, or should it include the entire DSP chain latency?
Thanks for the clarification, in any case ;D
-
A Delay filter in PEQ would not show up, because if it would then the audio engine would compensate for it, and you would not actually get any delay.
Any actual processing filter that needs to buffer audio data, but are not meant to introduce delay, eg. any FIR or IIR filters for example, would have some delay that should show up there.
That touches on the important part here - these delays are not meant to be perceivable in file playback, we measure them so the audio engine can adapt to them. Only in Live playback would you ever notice, as we can't read audio faster then realtime to compensate.
-
I see about 170ms on the first number yet I know the latency in my fir filter is 00s of ms more than this, shouldn't that show up here or is there some reason why that latency gets hidden?
-
I've always been interested in this number. I am seeing numbers like 1.2 msec delay from converter and upwards of 6,000 msec from input until heard.
-
A Delay filter in PEQ would not show up, because if it would then the audio engine would compensate for it, and you would not actually get any delay.
Any actual processing filter that needs to buffer audio data, but are not meant to introduce delay, eg. any FIR or IIR filters for example, would have some delay that should show up there.
That touches on the important part here - these delays are not meant to be perceivable in file playback, we measure them so the audio engine can adapt to them. Only in Live playback would you ever notice, as we can't read audio faster then realtime to compensate.
I love that this has been added.
Frankly JRiver's method of handling Video + Audio sync is the bees knees, lipsync is rarely if EVER an issue and when it is, well it's not JRiver's fault. I don't use audio re-clocking or anything either. I mean, it's just math (make sure that any delay introduced in the chain is compensated for) but I haven't really see another software player get this right.