Devices > Video Cards, Monitors, Televisions, and Projectors

Dropouts when bitstreaming Atmos through an HDMI 2.1 AVR with nVidia 3xxx GPUs

(1/19) > >>

Manni:
It was established a while ago that this issue was specific to 3xxx GPUs, possibly 4xxx GPUs, and it might be a hardware issue. The reason why I'm creating this new thread is because I have some new information so I'd like to see if anything can be done in LAV or MC to fix it, despite the fact that it might be specific to the hardware.

I'm also trying to make this thread specific so that other similar but unrelated issues are not reported here. If you have a different GPU, no HDMI 2.1 AVR or if you experience this with other sound formats, or when not bitstreaming, or with non-4K HDR content, please DO NOT POST HERE. Find a different thread, or create another one.

If I'm the only one with this issue, then it will be easy for Hendrik to do nothing, and I'll be the first to understand :)

If you do post in this thread because you experience long freezes or micro dropouts when bitstreaming Atmos through an HDMI 2.1 AVR with a 3xxx GPU, please provide the following info, as I do, so that we can see if there are some common elements causing the issue:

Motherboard: ASRock X570 Creator
CPU: AMD 5950X
Memory: 32GB
GPU: Zotac 3090 (no OC/UC) with 555.99 Studio drivers
HDMI 2.1 AVR: Denon X8500HA
Anything else in the HDMI A/V chain: HD Fury VRROOM, but it's after the AVR (so not in the audio chain) and the issue also happens with the VRROOM out of the chain.
OS: Windows 11 23H2 with all updates installed
MC: MC32 build 55 (it happens here with both direct sound and WASAPI, and some buffer settings can improve the issue, but not fix it)
Renderer: JRVR (but it also happens with madVR).

The new information I have is that I have found two workarounds for this issue:

1) Compromise immersive audio quality and not use bitstream. That's an obvious one, and not new. If you set MC to not use HDMI bitstreaming, LPCM has zero audio drops with Atmos. Obviously, you lose the metadata for immersive sound (Atmos or DTS:X), so this is only a workaround if you don't have any height speakers in your setup or don't mind losing the native immersive audio and are happy to simply upscale the base DTS:HD or Dolby TrueHD layer using Neural:X or Dolby Surround.

2) Select 8bits in the nVidia control panel, instead of 10/12bits. That's less obvious, and the new bit of info. If you set the driver to 8bit, MC has to dither so you get a bit more noise near black with 10-bit content. You compromise the picture quality slightly, but you can bitstream Atmos and have zero dropped frames. At least with the native refresh rate. If I use 119p for 23p, I got one micro audio drop in a 153 minute films, which is still a lot better than in 10/12bits. [EDIT got Atmos freeze/drop at 4K119 with 23p content today, so native frame rate seems like the only workaround. I’ll keep testing that way.]

3) [EDIT 14-August-2024]: I'm adding this third compromise (see this post https://yabb.jriver.com/interact/index.php/topic,139110.msg967014.html#msg967014 on page two of this thread for more details), which is to compromise gaming (no 4K120) and use a HDMI 2.0 input of the AVR to force TDMS. This allows to keep 10/12bits at 4K23, so no compromise on audio or video, just a compromise on gaming (no 4K120). Selecting a HDMI 2.0 EDID while still using a HDMI 2.1 input might allow to reach the same results (as it would prevent the GPU from using FRL5/6), but I haven't tested this for now.

So if you experience this issue with long pic freezes/audio dropout or micro audio dropouts when bitstreaming Atmos, please could you 1) post your detailed set up as I did above and 2) post if these two workarounds work for you? Note that if these workarounds don't help, you migght have another issue in your system (network stability, HDMI cable, etc) so you might want to isolate that first, for example playing the test film from an SSD or replacing your cables with HDMi 2.1 Premium certified cables to ensure that your issue isn't network or cable related. Atmos needs a bit more bandwidth, so it might be enough to trigger a dropout in some cases.

Please note that you often have to wait at least 30 minute, frequently up to 60 minutes, and quite often up to 90 minutes or more before experiencing any of these dropouts, so please test when watching a film at least 120min long. You have to watch it because although the long freezes/dropouts will show a few hundreds dropped frames in the OSD stats, the micro audio drops won't show any dropped frames. You can't just watch 20 minutes once and report "no Atmos dropout issue".

If you don't have any audio dropout issue when bitstreaming Atmos through an HDMI 2.1 AVR using a 3xxx GPU (or a 4xxx GPU), please could you kindly 1) check before posting by playing a couple of full two+ hours films in full that you actually don't have the issue and 2) provide as much information as possible about your hardware and your software setup?

@Hendrik (and other devs), do you have any idea why the dropouts go away in 8bits? Also, I've noticed that increasing the buffering to 150ms instead of 100ms in the audio device settings helps a bit. Unfortunately, setting buffering to any higher value causes a crash / prevents playback from starting. Is there any chance you could fix this buffering issue, so that we could try higher buffering values?

Thank you!

SamuriHL:
I have this issue but I won't have time to test until maybe this weekend.  I have a similar hardware configuration with an ASUS mainboard and an AMD cpu.  I'll get the full specs of everything later.  The difference for me is while I don't have an HDMI 2.1 AVR, what I DO have is the VRROOM in the chain which is HDMI 2.1.  That is splitting audio out to my AVR through its HDMI out port.  No audio is being sent to my display.  In any case, I'll post more information about my setup and whether the suggestions change anything when I get time later this week.  But you are not alone with the problem.

Hendrik:
The buffer size is limited by the driver, and the absolute size depends on channel and sample rate used - bitstreaming uses the maximum however, as bitstreaming TrueHD uses 8 channel at 192kHz, so the maximum buffer length is limited accordingly.

Manni:

--- Quote from: Hendrik on June 19, 2024, 09:12:59 am ---The buffer size is limited by the driver, and the absolute size depends on channel and sample rate used - bitstreaming uses the maximum however, as bitstreaming TrueHD uses 8 channel at 192kHz, so the maximum buffer length is limited accordingly.

--- End quote ---

Thanks for the explanation, makes sense. You might want to add a check so that the user can't select a forbiden/excessive size, as it looks like a bug when MC then crashes during playback.

Any idea why the dropouts go away in 8bits? Is it just a bandwidth issue, as 8-bit does reduce the bandwidth for picture, which might leave more room for audio? Anything that could be done about this to make it work in 10bits? 4K23 10bits is still TDMS, so it's not FRL related. 4K120 8its is FRL5 and it stil works much better (single micro drop in almost 2.5 hours) than in 10bits, which is still FRL5. I was hoping this might give you some idea. Can you reproduce the behavior I'm reporting with your 4xxx?

Manni:

--- Quote from: SamuriHL on June 19, 2024, 09:06:11 am ---I have this issue but I won't have time to test until maybe this weekend.  I have a similar hardware configuration with an ASUS mainboard and an AMD cpu.  I'll get the full specs of everything later.  The difference for me is while I don't have an HDMI 2.1 AVR, what I DO have is the VRROOM in the chain which is HDMI 2.1.  That is splitting audio out to my AVR through its HDMI out port.  No audio is being sent to my display.  In any case, I'll post more information about my setup and whether the suggestions change anything when I get time later this week.  But you are not alone with the problem.

--- End quote ---

Thanks, looking forward to your feedback :)

Navigation

[0] Message Index

[#] Next page

Go to full version