75-100ms variable audio sync range with Madvr, MPC-HC, and Denon AVR. Help plz.

[Framerate]

Hi everyone, I am struggling to get a repeatable audio sync baseline on my HTPC using a Sync-One2 hardware calibration device. This device measures the disparity between a white flash and a beep on flash-beep test patterns. These patterns can be found on some Spears and Munsil discs, like the 2023 UHD benchmark disc. I used makemkv to make mkv's out of the test patterns to use them for HTPC playback with madvr and MPC-HC.

The issue: My HTPC initializes a completely different audio/video timing offset range when I open and close MPC-HC (every time), or load a video (sometimes), or pause and play a video (every time).

Hardware & Software Chain:Gear: Win 11 | RTX 4070 SUPER | 32GB DDR5 ram | i7-12700k CPU | z690 PG Velocita mobo | DirectX 12 | Player Setup: MPC-HC (x64) | madVR | Denon S970H AVR | LG C5 OLED TV

A standalone Panasonic UB9000 player on this same AVR stays within 4ms–5ms for DTS even after pauses and plays. For Dolby TrueHD, it initializes between +55ms and +62ms audio offsync, then always jumps to around +95ms after the first/pause play, but then, crucially, stays within that same +90ms to +100ms range after further pauses and plays. For Atmos similar behavior with different numbers. The max ~10ms ranges and consistency of behavior stays the same for all audio codes with bitstreaming and PCM, though the exact numbers change.

Other weird issues on the HTPC. 1. I tried turning off bitstreaming, defaulting to PCM, and using MPC-HC built in audio renderer with Wasabi Push. With this scenario, the baseline measurements settled into a negative range (e.g., -30ms). However, on every successive flash/beep, the reading would steadily "crawl" upward by exactly 1ms: -30ms, -31ms, -32ms... up to -44ms, where it would snap back down to -29ms / -30ms and then repeat. This then happened with bitstreaming on or off. However, the timing range shifts completely every single time I close/open MPC-HC, reload a file, or hit pause and play.

On Pause/Play: A loop crawling between -30ms and -44ms will arbitrarily reset after a pause and start at -55ms or -10ms and then do crawl the same way within a 12-15ms window or so.

My Questions:What causes MPC-HC and madVR to lock into completely random, permanent clock presentation boundaries from handshake to handshake? If WASAPI Exclusive Push mode is active, shouldn't the player force a hard-locked start point relative to the video frame boundaries? Why is the audio engine exhibiting this distinct 1ms "crawling loop" drift, and why isn't the audio renderer automatically tracking the master video presentation frequency to prevent this reset phase cycle?

How can I completely bypass Windows/driver audio clock destruction on pause so that madVR, MPC-HC, Windows, and my Denon AVR maintain a singular unified hardware timing chain like a dedicated physical disk player?

In short, how can I fix this? Is it possible to get audio sync within a stable 5ms or 10ms range with a PC, or is it always going to vary like this much more than a blu-ray player? Is there any other app for PC that will lock in the disparity between the video output of madvr/MPC-HC) and the audio output of windows (or MPC-HC) so that even if one lags behind the other, that lag will at least stay the same each time I load the player or load a movie, and I can input that audio delay to fix it?

I don't like that Im getting 10ms discrepancy on Dolby tracks with my blu-ray player and AVR, either. Wish I could fix that. I am sensitive enough to notice it is off, but at least it is useable.

Also any suggestions about other sections or existent threads I could post this in would be appreciated. I hope there is a simple fix but I suspect it's a difficult issue and am not sure where to go to find someone who will know how to fix it, if that is possible.

[huhn]

directshow is inaccurate. this is not fixable.

if you are at 60 Hz 16 ms is a frame so the video renderer can at best get within that range of accuracy by jumping between 0-16 ms delay. at 23p it is 42 ms of varying audio delay. this is as good as it goes on a PC. a lossy audio renderer could do better but directshow when started has a very random audio delay. the first you need is absolute perfect A/V sync good luck with that on a PC.

[clsid]

MPC Audio Renderer in latest MPC-HC has an option to keep device active when paused. It then sends inaudible noise.

Disabling all power saving crap for hdmi audio driver might help as well. Google for registry tweaks for that.

[Framerate]

directshow is inaccurate. this is not fixable.

if you are at 60 Hz 16 ms is a frame so the video renderer can at best get within that range of accuracy by jumping between 0-16 ms delay. at 23p it is 42 ms of varying audio delay. this is as good as it goes on a PC. a lossy audio renderer could do better but directshow when started has a very random audio delay. the first you need is absolute perfect A/V sync good luck with that on a PC.

Is directshow what handles the audio?

Any idea why Im getting big jumps with Dolby on the Denon AVR from a regular 4K blu-ray player also, and why it then stays within the same 10ms range after the big jump?

[Framerate]

MPC Audio Renderer in latest MPC-HC has an option to keep device active when paused. It then sends inaudible noise.

It's greyed out on mine.

Disabling all power saving crap for hdmi audio driver might help as well. Google for registry tweaks for that.

Thanks.

[huhn]

Is directshow what handles the audio?

Any idea why Im getting big jumps with Dolby on the Denon AVR from a regular 4K blu-ray player also, and why it then stays within the same 10ms range after the big jump?

with mpc-hc yes directshow is the protocol that talks to the audio renderer and video renderer.

bitdsreaming is a black box you just give an relative unknown amount of audio to an audio device that does what ever with it.

edit.
if you want to see the audio sync or at least a relative part of it in real time use mpc-VR and set wait for vblank before present. the green graph will move away from the centre blue line where the theoretical audio sync would be perfect just from audio and video having different clocks or frame rate mismatches

[clsid]

You must uncheck "release device when idle first".

The problem is not with DirectShow or the audio subsystem of Windows. It is happening after that, so in driver/hdmi/avr/tv part of the chain.
Your standalone player has pretty much same problems.

[huhn]

it sadly doesn't the audio and video in a standalone player use the same clock generator for a PC it usual doesn't. iGPU on intel or amd some times actually do. hat's why the entire CRU stuff even exist. the issue of directshow is the starting point. it is actually a total none brainer in practice the offset is irrelevant.

but a blu ray player has issue thanks to Genlock.

[nevcairiel]

DirectShow has little to do with it, it provides a precise reference clock and audio/video with timestamps, the same as any audio/video chain would work on a PC. Competent renderers can sync that to VSYNC and minimize differences. If any do, who knows, most people use built-in Windows audio renderers even.
Any further issues are implementation limitations or bugs.

As for the actual issues:
- if no proper syncing is done, you can get an offset of +/- half a refresh, which might look like a full frame, but if its centered around 0, then the impact to the user is only half a refresh.
- Using a higher multiple refresh rate, like 120Hz for 24 fps playback, will drastically reduce the minimum offset, since its bound by VSYNC, of which you get more with higher refresh rate
- if the offset changes during playback, your video and refresh rate mismatch (clean multiples are OK too). Matching it through refresh rate changes or Re-clocking can practically eliminate this.

If you see 100ms or pause bugs, then thats just a bad implementation somewhere that doesn't sync to the clock properly. Who knows if its the video renderer or audio renderer.

[Framerate]

Thanks for the help guys. Rly appreciate.

You must uncheck "release device when idle first".

Thanks. Any downside to that? I did that in MPC-HC options -> playback -> output -> MPC Audio Renderer settings, and checked "keep device active when paused."

Disabling all power saving crap for hdmi audio driver might help as well. Google for registry tweaks for that.

In the registry editor in a folder 0000 and subfolder PowerSettings I turned IdlePowerState (type is Reg_Binary) to 00 00 00 00. ConservationIdle and PerformanceIdle were already at 00 00 00 00. Is that what you're referring to? If it is, is it redundant now with "keep device active when paused" checked?

The problem is not with DirectShow or the audio subsystem of Windows. It is happening after that, so in driver/hdmi/avr/tv part of the chain.

Guessing it is both PC and AVR because:

Your standalone player has pretty much same problems. True, but only with Dolby audio, and not nearly to the same extent.

Im using latest nVidia game driver. Should I switch to the studio one or does it not matter?

it sadly doesn't the audio and video in a standalone player use the same clock generator for a PC it usual doesn't. iGPU on intel or amd some times actually do. hat's why the entire CRU stuff even exist. the issue of directshow is the starting point. it is actually a total none brainer in practice the offset is irrelevant.

but a blu ray player has issue thanks to Genlock.

Thanks for helping. I thought Genlock helped keeped things synced. You're saying the opposite?

DirectShow has little to do with it, it provides a precise reference clock and audio/video with timestamps

Do those get lost going to the AVR or should a competent PC renderer have as little variance with my AVR as the Panasonic UB9000?

the same as any audio/video chain would work on a PC. Competent renderers can sync that to VSYNC and minimize differences. If any do, who knows, most people use built-in Windows audio renderers even.

Does MPC-HC audio renderer with Wasabi exclusive (event, push, etc) accomplish this or not? Is there anything I should use?

if no proper syncing is done, you can get an offset of +/- half a refresh, which might look like a full frame, but if its centered around 0, then the impact to the user is only half a refresh.

No proper syncing, meaning turn off v-sync? Switch to 119.88hz and with v-sync off I will get only half of 8ms variance, so 4ms approx?

- Using a higher multiple refresh rate, like 120Hz for 24 fps playback, will drastically reduce the minimum offset, since its bound by VSYNC, of which you get more with higher refresh rate
- if the offset changes during playback, your video and refresh rate mismatch (clean multiples are OK too). Matching it through refresh rate changes or Re-clocking can practically eliminate this.

Does it typically change during playback? That "Crawl" happened a couple times for me but mostly I get a new reading after pause/play, exit/reopen of MPC-HC, reloading the movie file, etc, but no drift besides that during actual playback.

I definitely dont want to trade bad audio sync for microstutter or video artifacts. Someone told me they get good audio sync with "reclock," not sure if they've measured it though. Google Ai says it doesn't work anymore and wouldn't help my issue but its answers are of course all over the place, so I put it to you guys.

If you see 100ms or pause bugs, then thats just a bad implementation somewhere that doesn't sync to the clock properly. Who knows if its the video renderer or audio renderer.

Google AI is recommending "MVR" for audio sync by the way. Dont know if that would help, and sounds like its video may not be as good as madvr with MPC-HC. But thoughts? It says MVR doesnt use windows at all for audio and keeps everything on the same clock.

Also says an HDFury vroom will 100% eliminate the problem on the AVR end.

Anything else I can do? Has this issue come up before? If you guys could get your hands on a sync-one2 device and start testing yourselves to see if there is a fix, I know that would have a much higher chance of success than my continuing to monkey with it, hah.

[Framerate]

The latest of many things Google AI has said, not saying any of it is true.

1. The DirectShow Design Flaw: Splitting the Clock Threads
When you load a movie in MPC-HC, the DirectShow framework splits the audio and video tracks into two completely independent, separate software pipelines (filters).

The Video Thread: Handed to madVR, which must align its output to your TV's physical VSYNC lines.

The Audio Thread: Handed to the MPC Audio Renderer, which talks directly to your Denon AVR via a WASAPI Exclusive hardware loop.
Because these are separate parallel software threads, the Windows Operating System CPU Scheduler handles them independently. When you hit play or unpause, the exact microsecond gap between when the video thread draws its first frame on a VSYNC line and when the audio thread initializes varies randomly based on background CPU load.

DirectShow has perfect timestamps, but it lacks an internal mechanism to micro-adjust or "slip" the audio playback start timing to lock it onto that rigid VSYNC line [1.0]. It simply drops the audio at the nearest frame boundary, creating that native 0 to 42ms software initialization roulette [1.0].

2. How mpv Player Achieves a Flat 0ms Natively
The mpv media engine does not use the Microsoft DirectShow protocol. It was engineered from scratch on a completely different architecture called a Single Master-Clock Core [1.0]

2. (With madvr/MPC-hc) Does setting IdlePowerState to 00 fix the AVR HDMI variance? Yes. This modification prevents the NVIDIA graphics card driver from putting the physical HDMI audio rail into a low-power sleep state during pauses. The hardware link stays electrically hot. (*But later it says this only helps keep the physical connection alive, but HDFury box is necessary to keep the AVR's decoder active so it does not change the sync after a pause/play. For bitstreaming anyway, not sure about PCM.)

3. Does checking "Keep audio device active when paused" eliminate it?No, not while bitstreaming. As we discovered, you cannot inject raw PCM silence into an active Dolby/DTS bitstream conduit.The second you pause, the bitstream track halts completely, forcing the driver to reset its format lines anyway.

4. What about the sudden bitstream dump after pauses? (The AVR guessing phase intervals blind)

None of our software or registry fixes have solved this yet. This is your primary remaining bottleneck. When bitstreaming, the HTPC sends audio data packaged as an encrypted bitstream. Because it is a closed track, your Denon AVR's internal decoder chip must process the stream completely blind to the video frame timeline. When you unpause, a burst of compressed data hits the wire. The Denon AVR captures that data at a randomized microsecond interval relative to its internal clock cycle, forcing it to guess the decoding phase layout. This is what causes those sudden jumps into entirely new 10ms–20ms sync ranges after a pause.

5. Does the HDFury box solve the bitstream guess error? Yes, it does. An HDFury device (like the VRROOM) sits between your HTPC and your AVR, acting as a permanent hardware buffer link. It keeps the AVR's internal decoder streams awake and fed with a continuous carrier wave. When you unpause, the data drops into an already running hardware timeline, completely eliminating the receiver's decoding phase roulette.

And it basically says that madvr-mpc at 119.88hz with idlepower set to 00 00 00 00 should only vary 4ms audio sync if doing PCM, and MPV doing PCM (even at 23.976hz) will be 0. To get <4ms while bitstreaming you need an HDFury device for both. But says mpv still has advantages for bitstreaming because (long answer):

2. The Bitstreaming Comparison: Why They Are NOT Identical

Both players do not experience the Denon receiver's bitstream guessing roulette on an unpause in the same way. The difference comes down to what happens to the player's internal software threads when you click pause

When you hit pause while bitstreaming in MPC-HC, the legacy DirectShow framework completely tears down and destroys its internal audio and video filter graphs.When you click unpause, the Windows CPU scheduler has to rebuild those separate threads from absolute scratch. This means on every single unpause, MPC-HC inflicts its software frame-boundary snap error (0 to 4.16ms error at 119.88hz) on top of the Denon receiver's decoding phase roulette. Because these two independent errors randomize separately and stack together, your sync readings wander erratically across a wider span.

When you hit pause while bitstreaming in mpv, its single-timeline core does not destroy its software threads. It freezes them perfectly intact inside your PC's RAM. When you click unpause, mpv does not run the CPU scheduler thread gauntlet again. It instantly drops the very next bitstream data packet onto the exact, running hardware video frame coordinate. The Result: mpv's software startup error stays at a flat 0ms [1.0].

The Sync Behavior: Without an HDFury, your sync will still jump when you unpause, but it will only jump by the Denon receiver's internal tracking error. Instead of a loose 25ms wandering loop (*not sure where it gets these numbers), mpv keeps the bitstream jumps locked inside a much tighter, predictable 10ms step bracket.

3. Summary of mpv's Advantages

To wrap it up, mpvÂ’s advantage over your optimized MPC-HC setup isn't just about letting you drop down to 23.976Hz. Its core advantages are: True 0ms PCM Precision: It delivers absolute, frozen timing perfection down to the microsecond on PCM, completely eliminating the 4.16ms DirectShow variance [1.0]. Thread Retention on Pause: It prevents the player from destroying its internal audio/video alignment states when pausing a bitstream, keeping unpause jumps significantly tighter than MPC-HC. Modern Codebase: It completely bypasses legacy Windows DirectShow split-filter vulnerabilities, making it immune to background CPU scheduler throttling or Windows update audio driver glitches.

No idea what's true there. Would prefer to use madvr-MPC. Dont want to pay for an HDFury either! :(

[huhn]

Thanks for helping. I thought Genlock helped keeped things synced. You're saying the opposite?
on paper yes



Do those get lost going to the AVR or should a competent PC renderer have as little variance with my AVR as the Panasonic UB9000?
a normal video renderer is slave to the vsync and it is slave to the audio clock. you have to fix a/v drift that's not job of the video renderer some have mitigation for that same for audio renderer like reclock that actually fix stuff using lossy resampling.

madVr at 120 will vary by around 8 MS an entire vsync cause all it can do is drop or repeat a vsync which is 8 ms long that'S the resolution it can play with if it does drop/repeated a frame when the async reaches 4 ms it will now be 4 ms wrong in the other way. SM doesn't care and is always technically in perfect sync.

if you have perfect sync then the starting situation matter and the sync at that point if a audio renderer and video renderer sync there first frame/audio output buffer they could stay in very good sync. normal video renderer like madVR go totally async start dropping repeating frames to match the audio and work from there. if check thsi with rtss it is insanely messy at start.

[Framerate]

on paper yes




a normal video renderer is slave to the vsync and it is slave to the audio clock. you have to fix a/v drift that's not job of the video renderer some have mitigation for that same for audio renderer like reclock that actually fix stuff using lossy resampling.

madVr at 120 will vary by around 8 MS an entire vsync cause all it can do is drop or repeat a vsync which is 8 ms long that'S the resolution it can play with if it does drop/repeated a frame when the async reaches 4 ms it will now be 4 ms wrong in the other way. SM doesn't care and is always technically in perfect sync.

if you have perfect sync then the starting situation matter and the sync at that point if a audio renderer and video renderer sync there first frame/audio output buffer they could stay in very good sync. normal video renderer like madVR go totally async start dropping repeating frames to match the audio and work from there. if check thsi with rtss it is insanely messy at start.

After messing with the power options, checking "keep device active when idle," and changing output hz to 119.18hz, Im down to ~11ms audio sync variance with DTS, and ~22ms with Dolby. Seems to be my typical AVR variance plus 8ms v-sync.

Is there any way to get rid of that 8ms from v-sync now?

Edit: Well I spoke too soon. It is more 30+ms with Dolby Atmos and 15+ms with DTS HD-MA, and when you switch the audio tracks back and forth the DTS will stay in its normal range but the Atmos will jump wildly. Pauses and plays exiting and reopening the player and shutting down and starting the computer have fairly minimal impact but switching audio back to atmos after changing something else will create a big difference.

Also, unlike with the Panasonic player, each type of DTS and Dolby and each different number of speaker layouts will change the numbers as well.

MPV player seems to have a similar baseline range of variance except that its readings consistently crawl by 1ms for each with each flash/beep a 10ms range or so.

PCM vs bitstreaming changes the starting numbers, but not the variance ranges, with madvr/MPC-HC. Maybe a little better but still similar.

Can any of this be improved?

[huhn]

cru try to get the clock deviation lower. also reclock. or try SM. you should also not bother with a bit of A/V sync as long as audio is >late< the human ear doesn't really care if it is just ~40 ms that's just a frame just moving your head changes audio video sync.