Devices > Video Cards, Monitors, Televisions, and Projectors
Dropouts when bitstreaming Atmos through an HDMI 2.1 AVR with nVidia 3xxx GPUs
SamuriHL:
Watching a movie in DTS-HD MA 5.1 and I got 2 drops. That's frustrating.
TheShoe:
Not sure if this is helpful, but I finally was able to experience multiple excessive video/audio issues playing the UHD full disc backup of The Hobbit Extended - The Desolation of Smaug via UHD menu playback. I am bit streaming the audio and this is served off an SMB share.
At various times - and it's not consistent on any part of the movie, the frame drop jumps and the repeated frames jump. Causes stuttering for 3-5 seconds and then the movie resumes normally until the next event. CPU/GPU/Network are all normal. Other movies - like the first Hobbit Movie - no issues. This movie is a mess.
Playback of the full rip via SMB to the Oppo 203 works perfectly - no issues.
If I remux the video into a single MKV file, no issues
If I create a particle to 0800.mpls (the movie), no issues
It seems that when I playback via full UHD/BluRay Menu, issues.
Setting bit streaming to off, still issues
Don't know what is different with the full menu playback, but for now I'll just particles for titles that experience this.
Manni:
All right, I wanted to update this thread because I did an in-depth debugging session with the 3090 and I *think* I've found a third compromise, which means no compromise on audio or video, but one on gaming... Here is what I did:
- I tried a clean install of Win10 x64 on a spare SSD (dual boot), with just MC installed. Got dropouts. This ruled out the software stack.
- I tried to take the VRROOM out of the chain, so I only had HTPC > X8500HA > TV. Got dropouts. This ruled out the hardware chain (besides the 3090 itself).
- I got a long audio+video freeze and realised that JRiver had just downloaded a new build while I was playing a film. I disabled auto-update and I've never had a long freeze/drop again (that was 10-15 films ago). If this is confirmed, I would call this a bug, because I don't see any reason for MC to do anything that could compromise playback. Could a dev confirm that MC only checks for a new build at launch, and not during playback? If it's possible during playback, could this be fixed?
Now, turning auto-updates off seems to have resolved the audio+video long freeze.
This means a few things:
1. The long audio+video freeze isn't specific to Atmos or bitstreaming, I experienced it (before disabling JRiver auto-update) on a DTS title using LPCM.
2. The 4xxx was most likely a fix for the micro audio drops, as what I remember was that I got long audio+video freezes, not micro audio drops. The possible network issue was likely a red herring. So if you have Atmos micro audio drops with a 3xxx GPU at 4K120, consider the 4xxx as a likely fix.
The 8-bit workaround mentioned at the beginning of the thread should have led me to test another workaround, which I used to use a while ago and forgot about, which is to have the HTPC on a HDMI 2.0 input of the AVR. This forces TDMS, and allows to have 4K23 in 10/12bits without any Atmos drops. You’re only limited to 8bits at 4K60.
This used to be an issue with some drivers newer than 532.03, as you would get a black screen when a HDMI 2.1 GPU was used that way, but it was fixed in 551.23.
Note that the output doesn't matter (both of the outputs of the X8500HA are HDMI 2.1 and I can use either without any issue).
I've now watched six full films with this set up (3090 >> HDMI 2.0 input >> TV) and have experienced no Atmos drops.
I'm going to do more checks to see if I can enable 8K Enhanced instead of 4K Enhanced in the AVR, and still get no audio drops.
I'm also going to see if I can bring the HTCP back to the HDMI 2.1 input and simply use a HDMI 2.0 EDID when I use it for video tasks (hence limiting it to a TDMS bandwidth) and then a full HDMI 2.1 EDID when I want to game at 4K120. But this will take a while and I wanted to share my third workaround right now, so others can test and see if it works for them too.
I might in fact keep the HTPC in a HDMI 2.0 input, as I can still game at 4K60 and the big advantage of doing this is I can use my Sony HDMI Headphones with the HTPC without having to put another VRROOM between the PC and the VAR to get the audio only to the Sony headphones.
One last thing, for those using a VRROOM, I kept having black screens with the latest fw, so I reverted to 0.34 (which happens to be the last fw with working JVC Macros) and the black screens seem to be gone.
So to summarise, here is my current workaround:
3090 HTPC with latest nVidia drivers (currently 650.81 studio) >> HDMI 2.0 input of the X8500HA >> VRROOM with fw 0.34 >> TV (Samsung S90C).
This gives me no audio compromise (Atmos + DTS:X), no micro Atmos audio drops, 4K23 at 10/12bits, no long video+audio freeze (auto-updates disabled in JRiver MC).
Main dowside is that I lose 4K120 for gaming, but I can live with that, at least until I get a 4xxx or 5xxx next year.
As always with HTPCs, YMMV
Good luck!
SamuriHL:
What happens if you set the VRROOM to matrix frl->tmds (mode 3)? Does that solve the problem?
Manni:
--- Quote from: SamuriHL on August 14, 2024, 08:51:36 am ---What happens if you set the VRROOM to matrix frl->tmds (mode 3)? Does that solve the problem?
--- End quote ---
It depends where the VRROOM is in the chain, and on which output the TV is. I'm not going to do any of these tests for now, as I'm quite happy to have the 3090 going to a HDMI 2.0 input (it allows me to use my Sony HDMI headphone without having a second VRROOM in the chain).
However, given that setting the driver to 8bits (which forces the bandwidth to TDMS) resolves the micro-audio-drops issues, I would say that anything that forces a TDMS bandwidth on the GPU output should work:
- Setting the driver to 8bits
- Using a HDMI 2.0 switch
- Setting the AVR to 4K Enhanced instead of 8K Enhanced
- Using a 4K60 8bits EDID
Etc...
I have only validated using a 4K (HDMI 2.0) input in the AVR at this stage.
Having spent a week on this already, I need to get back to work before I don any further testing re possible other workarounds for the 3xxx ampere bug.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version