Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jmone]

Chatting to Murray.  In case there is nothing in the logs, he is going to test without an HDMI Splitter in the chain in case that is impacting things as well.

[murray]

Folk I can now report the audio dropouts Ive been recently having was due to a new HDMI 1x2 splitter in the chain, I have now removed it and the dropouts have gone! Hopefully this is the end of this story. Thanks to all that offered help.

[Manni]

I also experienced ATMOS dropouts with the latest versions of MC30 and MC31.

For some reason, it seems in my case to be caused by registering the LAV filters in the JRiver plugin folder (so they can be used by other software, such as MPC-BE.

Running the three install.bat caused the dropouts. Running the three uninstall removed the dropouts.

I only have ATMOS dropouts with JRiver. When present, there are no dropout with MPC-HC (using internal LAV filters) or MPC-BE (using the registered JRiver LAV filters).

Registering the LAV filters in JRiver plugins doesn’t always cause the dropouts. At the monument, they are registered and there doesn’t seem to be dropouts, either in JRiver or MPC-BE.

I’m using latest Windows 11 and latest nVidia studio drivers for a 3090, in case devs want to try to reproduce this.

[JimH]

For some reason, it seems in my case to be caused by registering the LAV filters in the JRiver plugin folder (so they can be used by other software, such as MPC-BE.

Don't use MC's LAV for that purpose.  Just install LAV in another location as needed for other programs.  The two can co-exist.

[Manni]

Thanks, but when I do this MPC-BE doesn't work. I disable all the internal filters, add/enable the external LAV filters, configure them, but when I play a file the video decoder reports inactive hardware. I tried this with 77.2 LAV Filter x64 install. The only way to get it to work is to register the filters in the JRiver/plugin folder. That's always been working fine, it's only a problem and causes Atmos dropouts with MC30 and MC31. I've been using it that way with all versions up to MC28 without any problem.

EDIT: I must have done something wrong in my previous attempt, I've reinstalled LAV Filters x64 on my laptop and this time the filters are detected fine in MPC-BE. I'll try again on the HTPC.

[Manni]

Even with LAV Filters installed separately for other software, I'm still getting ATMOS audio drops (from a few frames to up to 1-3 seconds) in JRiver, with a frozen frame.
Any idea what might be causing this?

[jmone]

Would just be guessing.  For Murray it was a splitter, for Vern it was not using WASAPI.  Posting a log from MC of when it happens might give Hendrik some clues. 

[Manni]

Would just be guessing.  For Murray it was a splitter, for Vern it was not using WASAPI.  Posting a log from MC of when it happens might give Hendrik some clues.

Thanks, I'll try bypassing my VRROOM to see if it helps.

However, the VRROM doesn't cause any problem with MPB-BE with madVR when playing Atmos, so even if it's the cause that won't exclude a problem specific to JRiver.
I have my Denon AVR with WASAPI as the default device, so that's not the issue.

[murray]

I once had a Vertex in my system so I could run two displays, JVC NZ9 and Dell 4K monitor (limited to 8bit) in my foyer, I could never bitstream for my atmos setup as I had bangs and clicks, LOUD! I removed the Vertex and all came right after years of missing out on my atmos. I then had the problem of no foyer moniter and I needed it.....

So I started this time with a Blustream splitter, with a scaler on one side for the monitor, but it would only pass 8bit and for PCM films 2 channel only.

I then moved to another splitter that allowed 7.1 channel PCM, also limited to 8 bit but this one introduced auto dropouts, solved last week be bypassing the splitter for the audio. However Im still limited to 8bit due to the splitter.

Ive ordered two more splitters from Amazon and over the last week spent approx $700 on splitters, but now I have very little faith in them.

I though all it could be was JR all the time, but I was mistaken.

[Manni]

I once had a Vertex in my system so I could run two displays, JVC NZ9 and Dell 4K monitor (limited to 8bit) in my foyer, I could never bitstream for my atmos setup as I had bangs and clicks, LOUD! I removed the Vertex and all came right after years of missing out on my atmos. I then had the problem of no foyer moniter and I needed it.....

So I started this time with a Blustream splitter, with a scaler on one side for the monitor, but it would only pass 8bit and for PCM films 2 channel only.

I then moved to another splitter that allowed 7.1 channel PCM, also limited to 8 bit but this one introduced auto dropouts, solved last week be bypassing the splitter for the audio. However Im still limited to 8bit due to the splitter.

Ive ordered two more splitters from Amazon and over the last week spent approx $700 on splitters, but now I have very little faith in them.

I though all it could be was JR all the time, but I was mistaken.

Well, given that it ONLY happens with JRiver (and not with MPC-BE also playing Atmos), I'm afraid it has to be JRiver, even if taking the splitter out resolves the issue.

I can take my HD Fury Vrrom out of the chain temporarily, but I can't take it out permanently.

The issue might be related to JRiver BD Menus (I have them on, that's the main reason why I use JRiver over other players). I'll try disabling menus and see if it improves the Atmos dropouts.

[jmone]

I'd not be surprised if it is the combination between MC and whatever chipset these splitters use.  Thing is, we have to help narrow it down, provide logs etc.  Just say it's "broke" leaves Hendrik searching for a needle in a haystack especially given he is unlikely to have the varied range of equipment we all have.  From what I can tell, this issue seems to
- only have come up recently
- restricted to setups where there is something in the Audio path between the HTPC and the AVR
- is only when Bitstreaming ATMOS

[Manni]

I'd not be surprised if it is the combination between MC and whatever chipset these splitters use.  Thing is, we have to help narrow it down, provide logs etc.  Just say it's "broke" leaves Hendrik searching for a needle in a haystack especially given he is unlikely to have the varied range of equipment we all have.  From what I can tell, this issue seems to
- only have come up recently
- restricted to setups where there is something in the Audio path between the HTPC and the AVR
- is only when Bitstreaming ATMOS

There is nothing between my HTPC and the AVR. The VRRoom is after the AVR, before the PJ. That’s why I think it’s an unlikely culprit as it’s not in the audio path. The HTPC goes from the HDMI 2.1 out of the 3090 to the HDMI 2.1 input of the X8500HA.

[jmone]

Then I have no idea what is up.  You're going to need to log it I guess!

[Hendrik]

Logs don't help much because they don't tell you why hardware does something. If you are having an isolated problem, you'll have to do some testing and figuring out yourself, there is nothing we can do to diagnose your system.

[Manni]

Logs don't help much because they don't tell you why hardware does something. If you are having an isolated problem, you'll have to do some testing and figuring out yourself, there is nothing we can do to diagnose your system.

Yes, I agree logs won't help, I’m doing detailed test right now, will post results soon.

[JimH]

There is nothing between my HTPC and the AVR. The VRRoom is after the AVR, before the PJ. That’s why I think it’s an unlikely culprit as it’s not in the audio path.

Could you remove it anyway, just to test?

[Manni]

Hi Jim, no need to remove it (I can't do so easily due to cabling etc).

Anyway, as I suspected hardware is not the problem (I don't see how it could be when there are no ATMOS drop outs with MCP-BE or MPC-HC)

Here is what I did:

Preparation:
Deregistered madVR / LAV
Uninstalled MPC-BE, MPC-HC, JRiver (complete uninstall, including library), LAV filters
Clean up registry, program files, program data, appdata/roaming etc. of any reference to the above.
Moved all test titles to cache SDD on the Unraid server to rule out any HDD glitch.
Bandwidth reported by UnRAID during playback between 8 MB/s and 13 MB/s, average around 10 MB/s. Can't be taken literally of course as UnRAID stats are not real-time or exact, but that's all normal and as expected.
Disabled all scheduled tasks in Windows

Installation
Install JRiver MC 31 build 38 with default settings (RO JRVR).
Disabled background library import.

Hardware:
ASRock X570 Creator, AMD 5950x 3.4Ghz, 32GB RAM, Zotac 3090 24GB (BUS interface confirmed PCIE 4.0 x16)

Software:
Windows 11 x64 Pro  22H2 build 22621.1992 up to date.
nVidia Latest studio drivers v536.40
3D settings: Vertical sync: on, power management mode: max performance, prefered refresh rate application controlled
GSync: disabled
Desktop color settings set to reference
Video settings set to use the player
Desktop resolution set to UHD  (native) 4K 23p 10bits RGB Full

Test title:
John Wick 3 4K UHD Blu-ray, 1:1 rip from original disk to BD Folders, moved to SSD for testing

During playback (all tests / all video chains) JRiver reports 3840x2160 at 23.976hz VSYNC measured 23.976hz Overall 0.5ms avg / 0.5ms peak, so I think we have some rendering headroom All good up to that point.

Playback chain for the first two tests:
HTPC 3090 HDMI 2.1 Out > Denon X8500HA HDMI. 2.1 In > HD Fury VROOM HDMI 2.1 Out 2 > EZKOO HDMI 2.1 KVM > LG 4K Monitor HDMI 2.0 (supports 23.976hz refresh rate, single / primary monitor)

At the beginning of each test, I enable the JRVR OSD display (CTRL-J), reset the stats after a few secs to discard normal/expected initial frame drops (CTRL-R), and make sure I have 0/0 report at start of playback after the first ten seconds of playback. If it still drops frames after ten seconds of playblack, I don't reset. Obviously I don't touch the mouse or keyboard or pause or do anything during the test. Just play and watch the stats.

1) First test run with no change in JRiver settings at all (so LPCM audio, no bitstreaming, no bd menus) to get a baseline on the LG 4K Monitor (Audio PASS, Video PASS)
Playback for 25 minutes (LPCM, no BD menus)
Results: 0 frame drop / repeat, no audio drop out (multi in) There are at least three known scenes where audio dropouts happen. Usually by that time I would have got at least one big audio dropout in JRiver and many frame drops. None with these baseline settings.

Stopped playback
Enabled HDMI bitstreaming to get ATMOS, changed default device set to Denon WASAPI

2) Second test run to establish baseline with bistreaming and ATMOS on the LG 4K (Audio PASS, video FAIL)
Playback for 25 minutes (Bitstream ATMOS, no BD menus)
Results: 2 frame drops, 1 frame repeated, no audio drop out At the beginning, a few drops happened, I reset the stats a few times, then one happened and I left in on. This was in the first 30 secs of playback. No more frame drops after that in 15 minutes, then another one happened. Then a frame repeat about 20 minutes in.

So while there are no Atmos audio drop outs, the video performance is not perfect with 2 drops and 1 repeated frame. I don't really care about A/V performance on this monitor, I only use it for testing to save laser/bulb time, and the EZKOO KVM adds complexity that might cause these frame drops. So at this point I moved to the JVC. For these tests (audio drop outs with Atmos), it's still a PASS on the LG 4K.

Stopped playback, switched LG Monitor off
Changed the video chain to the PJ, which is what I use for normal playback (JVC NZ8, using a custom EDID in the VROOM to limit bandwidth to 4K120 4:2:0 and prevent FRL, to rule out one possible complexity, so only TDMS bandwidth HDMI 2.0 4K60 4:4:4 18gbs max) New Playback chain: HTPC 3090 HDMI 2.1 > Denon X8500HA HDMI. 2.1 > HD Fury VROOM HDMI 2.1 Out 1 > JVC NZ8 (single / primary monitor) This is my normal playback chain, the one I care about for video and audio performance. It's optimised and works flawlessly re Atmos bitstream with all other software (both MPC-BE and MPC-HC).

3) Third test run to establish baseline with bitstreaming and ATMOS on the JVC (Audio PASS, Video PASS) Playback for 25 minutes (bitstream ATMOS, no BD Menus)
Results: 0 frame drops, 0 frame repeated, no audio drop out This confirms that the frame drop/repeat with Atmos/bitstream on the LG was specific to the LG 4K and that video chain.
Now that we have the Bitstream / Atmos validated with the JVC, we know that whatever causes Atmos drop outs in my set-up with JRiver is due to some JRiver setting, unless it was solved by the cleanup/uninstall/reinstallation.

I'm going to go back gradually to where I was settings-wise, checking playback after each change, to try to establish what causes the drop out.

At the very least these first tests rule out a hardware issue.

Potential causes:
BD menus
HDR / Scaling / Rendering settings
Conflict with other software that have been uninstalled.

I'll only introduce other software in the mix if I manage to get back to my full JRVR settings and still have no ATMOS dropout issues.

Stay tuned!

At least we know that after a full clean / reinstall and with default rendering / processing settings there doesn't seem to be any Atmos dropouts or frame/drop repeats here and no hardware incompatibility.

That's good news!

[Hendrik]

Getting rare video drops when bitstreaming is somewhat normal unless the refresh rate is perfectly tuned. The audio should not drop out at that point. So that all sounds ok.

Its certainly possible that its related to BD Menus, it uses a very different buffering model due to the interactive nature of it. And I'm not sure how many people realistically use it with bitstreaming on a regular basis.
If thats the case its also something we can look to investigate further.

[Manni]

Getting rare video drops when bitstreaming is somewhat normal unless the refresh rate is perfectly tuned. So that all sounds ok.

Its certainly possible that its related to BD Menus, it uses a very different buffering model due to the interactive nature of it. And I'm not sure how many people realistically use it with bitstreaming on a regular basis.
If thats the case its also something we can look to investigate further.

Agreed, though the refresh rate is perfectly tuned now that nVidia has fixed their wrong 23p refresh rate, so there shoudn't be any drops at all.

I ran another test before changing any setting and got 2 drops in one hour (on the JVC) which shouldn't really happen (assuming the refresh and composition rate reported in the JRiver OSD are reliable. With identical composition and refresh rates of 23.976 (with the occasional drop to 23.975) I shouldn't have drops for days.

I'm moving the test title to my local data SSD (Samsung NVME 2TB) to rule out the Unraid server and the network entirely, even though I get no frame drops with the other players. That will be one less factor ruled out.

If I still get occasional frame drops when playing the file from the local SSD, I'll check with MPC-HC 2.0 (as its LAV filters are internal / standalone, so can't conflict with the JRiver ones, I think it's 77.1 in that version) and I'll see if I still have frame drops when bitstreaming. If I don't, I think we should resolve the frame drops in JRiver before I go any further, because with 0.5s of rendering time, there really shouldn't be any.

Are you happy with my nVidia settings re vertical sync? I can't think of anything else that could matter as Gsync is off and power is on max performance.

I'd really like to make sure that there are zero frame drops before I start changing any settings in JRiver, otherwise

[Manni]

OK, local SDD seems to have tamed the odd frame drop / repeat. I'll park this for now, I'll test later if there is a difference with other players (and I'll create a separate thread as it's a separate issue), otherwise it's a network/UnRAID performance issue that has nothing to do with JRiver.

I played the test title for 45 minutes, 0 drop/repeat, no audio ATMOS drop-out.

So now that we have a known-good baseline, I enabled BD Menus and am testing that now.

[Manni]

Right, so good news, it doesn't look like BD Menus is the culprit, I played 65 minutes of the test title and got no Atmos drop out and a single frame drop, about 20 minutes in. Not ideal but not always avoidable, so I'll count this as a PASS for for audio and video.

I'm now going to bring back my usual JRVR settings, and we'll see what happens with more usual render times (still very reasonable, I’m under 25ms with madVR, but I'm not bringing madVR in the mix yet).

Stay tuned.

[Manni]

Here are my JRVR settings (I only use a single profile for now):

Loaded quality preset (reset all profiles checked)
Enabled advanced options

GENERAL
No change

HDR
Target nits set to 95nits (that the peak nits for my JVC NZ8 mid laser AP -4 with P3 filter at around 1800 hours)
Contrast set to OLED (laser with laser dimming)
Disable contrast recovery when tonemapping (as there is already a contrast setting with manual spline)
Select Spline with contrast at 0.5 default
Enabled 10-bit output for SDR videos

CALIBRATION
P3, 2.4, calibration disabled, geometry correction disabled

SCALING
Everything left at default except upscaling set to FSRCNNX 16 and downscaling to Jinc. Note: I'm playing UHD to UHD for these tests, so the only scaling involved is chroma upscaling.

PROCESSING
No change

ADVANCED
No change (blue noise, HDR DTM, Histogram, convert HLG to HDR10 and use Tricubic for gamut checked, everything else unchecked).

TEST RESULTS
With these settings, JRVR reports 1.5ms render times during the playback of the test file (4K UHD HDR Atmos), which is impressive (and surprising).

I got two frames dropped after 60 minutes of playing the test title. More than I like, but it looks like I won't be able to avoid a drop here and there. No ATMOS audio drops. So that's a PASS.

This seems to give a clean bill of health to JRiver when no other software is involved, at least from an Atmos bitstream point of view (I'll deal with the frame drops later / separately).

Moving on to adding madVR (I'll upgrade the default build to V113 and won't register it for now to make sure we still only have standard JRiver install).

In the next step if this is still working, I'll test with MPC-HC (internal LAV Filters 77.1) and I'll install LAV filters for MPC-BE (77.2).

Question for Hendrik:
For use of LAV Filters in MPC-BE, do you prefer if we install the latest LAV in the appdata/roaming/jriver/plugin (copy files, run install.bat as admin for video, audio and source to register the JRiver filters and have a single installation of LAV filters) or do you prefer that we install the standard LAV Filters with its own installer that installs in its own program files folder and registers itself separately for use with other software?

I've used the first method for years, but in my testing it looked at some point as if registering LAV Filters in the JRiver plugins folder was causing ATMOS drop outs and deregistering was clearing them. I don't think it's connected anymore, but I'd rather install LAV Filters in the way you recommend to limit conflicts between JRiver and other apps.

[JimH]

Don't replace any plug-ins JRiver uses for video.  Don't use them for any other application.  Either could cause problems.

[Manni]

Don't replace any plug-ins JRiver uses for video.  Don't use them for any other application.  Either could cause problems.

OK so for madVR renderer you want me to:
Disable madVR in JRiver (re-select JRVR)
Delete the madVR folder in JRiver\plugins
Install madVR in its own folder in program files (V113) and register it with install.bat
Select custom mode in JRiver and select madVR for video renderer, hoping it will be detected?
I don't see any other way to be able to use madVR build 113 with JRiver and also with other apps (MPC-BE, MPC-HC etc) and make sure that the registry settings are valid and for the same version (I have no use for 0.92.17 that's installed by JRiver, it's way too old).

For audio/video decoding and splitter you want me to:
Leave the LAV installed in plugins exclusively for JRiver use
Select custom mode and add video & audio decodes and source splitter to be able to do advanced settings
Install LAV Filters using the LAV Filters standard installation (77.2) for use with other apps (mostly MPC-BE)
There won't be any conflicts if different versions of LAV Filters are concurrently installed on the same PC?

[JimH]

Don't do anything for JRiver's use.  JRiver will take care of itself.

[Manni]

Don't do anything for JRiver's use.  JRiver will take care of itself.

I'm talking about JRiver use. How do I use madVR 113 build in JRiver if you don't want me to update the old 0.92.17 installed by JRiver?

[JimH]

I'm talking about JRiver use. How do I use madVR 113 build in JRiver if you don't want me to update the old 0.92.17 installed by JRiver?

Don't ever do anything manually.  JRiver will do it for you.

[mattkhan]

JRiver needs to use a more recent madvr then

There's no problem using beta madvr versions (whether supported or not)

[Manni]

Don't ever do anything manually.  JRiver will do it for you.

JRiver doesn't update the 0.92.17 version of madVR to anything more recent AFAIK. Has this changed and to which version does it update when it does? When does it do it?
It's definitely the old version that's installed initialy, and it hasn't updated it yet. I've never seen JRiver update madVR since the 0.92.17 version happened years and years ago.
The more recent versions and not official ones, so not detected by JRiver in the update channel.

[Manni]

JRiver needs to use a more recent madvr then

There's no problem using beta madvr versions (whether supported or not)

I never had any problems update the old madVR version in the JRiver plugin folder, but I am told that I shouldn't so I'm asking for the "proper" way to do it, as the version installed by JRiver is completely out of date and not usable for HDR tonemapping. Build 113 is the last non time-limited version of madVR, but it's not an official release.
No versions of madVR are currently supported anyway, included the last official one (0.92.17).

[JimH]

Call us conservative.  We update plug-ins only when there is a good reason.

Do NOT change them for any reason.

[Manni]

The main downside of build 113 is that it breaks smooth motion, which I don't use. But it's a huge improvement in HDR tonemapping.

The version of madVR installed by JRiver is 0.92.17. It's not usable for HDR tonemapping.

So please let me know what is the RECOMMENDED way to upgrade 0.97.92 to build 113 so that it can be used in JRiver, otherwise I'll just do it my way (overwrite JRiver files in the JRiver plugin folder and run install.bat to make it available to other apps).

It's always worked fine, so I'm happy to follow a different procedure if you prefer, but 0.92.17 is not an acceptable option if that's all that JRiver offers.

As JRVR doesn't support vertical picture shift and as there is no ETA for that, JRVR is not yet an option either.

[mattkhan]

Call us conservative.  We update plug-ins only when there is a good reason.

Do NOT change them for any reason.

I don't see any difference at all between this and the custom renderer option, either way you end up using something that isn't packaged by jriver.

[Manni]

I don't see any difference at all between this and the custom renderer option, either way you end up using something that isn't packaged by jriver.

I agree.

However, I will follow the "don't touch any of the JRiver files" instructions and will do the following:

Select JRVR in JRiver
Delete the installed madVR folder in JRiver plugins (to make sure there is no other version installed)
Install madVR build 113 in its own folder, register it for use by all software
Setup a custom mode in JRiver and select madVR as the renderer. Hopefully, it will be the external one and there won't be any conflict as I won't be using an internal one.
Install LAV Filters with the official installer in its own floder for use with external software, and leave the one in JRiver untouched.

If Hendrik disagrees with this approach, please let me know.

[Manni]

So I went ahead, installed and registered madVR build 113 in its own folder in program files.
When you only do this, it's not possible to select LAV in custom mode, so I installed the official 77.2 Lav Filters installed, enabled bitstream in audio, selected D3D11 and my 3090 (to enable copyback for madVR black bar detection, as it doesn't work in native) and enabled the tray icon for LAV Audio, Video and Splitter.
In custom mode, I have madVR as the video renderer, LAV audio as audio decoder, LAV Video as video decoder and LAV Splitter as splitter/source.
For some reason, even though I didn't touch the madVR settings in JRiver settings, JRiver re-created the madVR folder in plugins with the old 0.92.17, but it's not used during playback in custom mode.

In playback, I get madVR build 113, and the external LAV Filters (easy to see as the tray icon shows, it's not the case when it's the internal LAV filters, unless you configure them that way).

I'll run some tests later with madVR to see if this has broken anything re ATMOS dropouts. I'll update the thread when I have results to share.

[Manni]

All right, for these evening tests I went back to my 4K LG monitor chain, given that we also had a few frame drops with the JVC. This will save some laser time as here are the results:
Played test title for 60 minutes (local SSD)
Frame dropped 1, no repeated frames, 1 presentation glitch. No Atmos dropout. So a PASS with external madVR build 113 and external LAV 77.2 in custom mode.
This is with the default madVR settings, so low render times under 5ms, default queues (16, 8, 8, 8 ).
Now on to restore my usual settings for madVR build 113, which should bring us up to around 25ms render times.
Stay tuned...

[Manni]

When I tried testing my usual madVR settings for build 113, I noticed that it was build 0.92.17 that was used by JRiver.
So I had to de-register madVR from its own folder and move it to the JRiver/plugin folder.
Rendering times were around 10-12ms, and I got only 1 dropped frames but 10 presentation glitches, which isn't acceptable.
This is with the same rendering queues settings as in the previous test (16,8,8,8). Queues remain full. I haven't tried to play with lower presentation frames in advance yet.
However, no ATMOS audio drop out. So it's a PASS for Audio and a FAIL for video.
I'm going to test MPC-HC and MPC-BE to see if they produce the same amount of dropped frames / glitches.
In my recent experience over the last few weeks, they don't. JRiver produces more than the other players as soon as you add external software. I've never had any ATMOS dropouts with the external players either.
Note that I've used JRiver as a player for years and have never had any dropped frames or ATMOS audio dropouts (up to MC28 or 29 a couple of years ago, with a 1080ti).
But many things have changed in the meantime: version of JRiver, version of Windows, nVidia drivers, and hardware (this is a new rig with a 5950X and a 3090).
I just haven't used it as a HTPC in the last couple of yeard, since I upgraded the rig, which was primarily a video editing / gaming rig.
I've only started recently to try to recommision it as a HTPC.
Only to provide some context for these tests.

[Manni]

Before checking with external software, I wanted to do one last check with JRiver, given that when I tested madVR 113 with default settings I had no dropped frames.

I reset the madVR 113 settings to default, then I manually set my options for tonemapping etc.

I watched an entire film (2 hours) and got 1 dropped frame and 1 glitch. I can live with that

So as far as I'm concerned, the ATMOS dropout issue with JRiver is resolved (and the video drops with madVR as well). [Unfortunately, it wasn't. Keep reading!]

As to what might have caused it (and resolved it), your guess is as good as mine, as I have documented all the steps I went through to debug and fix.

If we set aside the full/clean uninstall / registry cleaning / task scheduler disabling, the main causes I can see are:
- For the ATMOS dropouts, having updated the JRiver LAV filters and installing them so they could be accessed by other players, which is what I've always done without any issue until MC29 (I skipped MC30). I think I had noticed at some point that registering the filters made the issue happen and de-registering them made it go, but it wasn't 100% full proof.
- For the video dropped frames with madVR 113, most likely my registry settings that I was re-importing. Starting from scratch with the build 113 default seems to have fixed it for now.

So if you have this issue and if it's software based (I am very doubtful about the idea that it could be hardware based, it certainly wasn't in my case), here are what we've identified as NOT being involved in my situation:
- Hardware (switch, AVR, etc)
- BD menus in JRiver
- madVR up to build 113

If you're experiencing dropouts and would like to try to resolve them, here are my recommended steps (many of these might be unnecessary, but given that I'm not sure which one allowed me to resolve the issue, I'll list them all, except those related to the registry and hidden folders. If you know what you're doing, you'll know where to find them. If you don't know where to find them, better not to try):
- If you have registered LAV filters in the JRiver plugin, deregister them (right click uninstall.bat for audio, video and splitter and run as administrator).
- Uninstall JRiver
- If you have replace any of the JRiver files in the plugins folder, delete the JRiver plugin folder to make sure that they are all reinstalled from scratch when you reinstall JRiver
- Reinstall JRiver
- If you're using JRVR and no other player, you should be good to go.
- If you want to use LAV with other players, install LAV separately with the LAV Filters installer, in its own folder. Do not update the LAV filters in the JRiver plugins folder and register LAV there.
- If you want to use madVR 0.92.17, simply select madVR RO in JRiver and you're good to go.
- If you want to use a more recent version of madVR with JRiver, update the madVR files in the JRiver/plugins folders and run the install.bat as an admin if you'd like to also use it with other players (NOTE: this step is NOT recommended by the JRiver team, they advise to use the included madVR version and not touch it. Problem is that it's the version that will be used by JRiver if you install madVR in its own folder and register it for other software.
- If you use only JRVR in JRiver and want to use madVR with other software, it's probably safer to install it in its own folder and register it there. It won't be used in JRiver, but you should be able to use it in other players. There might be issues with registry settings though, that's why I went for the step above instead.
- If you had frame drops issues in JRiver with madVR, reset madVR settings to default and change your settings manually instead of importing your previous registry settings (or old settings.bin file). That seems to have resolved it for me, at least for now.

It took a while but I'm glad to be back where I was two years ago, with JRiver able to use madVR build 113 without any significant dropped frames or presentation glitches, and the ability to use both LAV and madVR with other players when I need to (it's not often as I love JRiver and use it as my primary player for almost everything when I use the HTPC as a source).

Overall, there was nothing wrong with JRiver in this area, mostly things that used to work for years that have broken in the last two years when using external software / players as well as JRiver.

If the team sees anything wrong or potentially dangerous in my suggested steps, please comment and I'll amend them.

 

[Manni]

Unfortunately the Atmos audio drop outs with JRiver came back today, so I guess I'm back to square one.

It took a few full films before it happened again. I watched John Wick 1 and John Wick 2 without any issues. Then I got many dropped frames and a lack of audio sync while watching Zootopia with my daughter last night. And I had a first Atmos audio drop out this morning while watching John Wick 4. That was with madVR, so I set JRiver to JRVR and got another Atmos audio drop out while playing Zootopia, which seems to be a problematic title for some reason. It might be due to seamless branching, as I noticed that Zootopia had some.

Anyway, the methodology I applied in the last few posts is pointless if it can take that long for the issue to occur. None of the steps above are validated, given that the drop outs could have happened at any point if I had played enough content. My recommendations above are therefore worth nothing. I would have to leave a few days between each steps, at least the main ones, to validate them. Not feasable.

I'll try to rule out any hardware incompatibility when/if I find the time to re-route HDMi cables etc, which is not easy to do in my set-up due to cable length and accessibility.

In the meantime, I'll use another player. That way I can at least validate if the drop outs only happen in MC31 (and MC30, as I experienced them with it as well) or not. I've never had any Atmos drop outs in any other software during all my recent testing, at least when I had up to three drop outs in one hour in John Wick 3, but as I mainly used JRiver, that's not really enough to validate. I could have the issue with other players and have not played enough content with them to produce the Atmos audio drop outs, if it can take up to 9 or 10 hours of playback before I get one.

I'll start with JRiver MC29, as I've never had any Atmos audio dropouts with it (or any previous JRiver version I've used, back to MC19).

I'll update the thread when/if I find anything conclusive, but I'll take my time.

[JimH]

Check your Windows power settings.

[Manni]

I've tested with MC29 and it makes no difference. Zero drop outs in a 2.5 hours non-Atmos film (Goodfellas) and an audio drop out as soon as I played an Atmos title (Ghostbusters Afterlife). So going back to previous versions of JRiver doesn't seem to make any difference.

I thought about differences from my last working HTPC and the main relevant difference is the GPU (3090 vs 1080ti). That made me think about the Atmos dropout bug with nVidia when using a HDMI 2.1 AVR (mine is a Denon X8500HA, I don't use EARC) that has been in the known bugs list for a while:

[NVIDIA Ampere GPU]: With the GPU connected to an HDMI 2.1 audio/video receiver, audio may drop out when playing back Dolby Atmos. [3345965]

This was supposedly fixed in recent drivers, hence why I didn't pay attention to it. It turns out that it's still not fixed for many people, and that many owners of Ampere GPUs have Atmos dropout issues even with recent nVidia drivers that supposedly fix it.

Here is a thread about it: https://www.reddit.com/r/nvidia/comments/whan6h/the_unfortunate_fix_for_dolby_atmos_audio_drops/

The latest nVidia studio driver (536.67) that I was using in my latest tests apparently has another audio-related fix specific to Ampere GPUs:

Fixed General Bugs
Increase in DPC latency observed in Latencymon for Ampere-based GPUs [3952556]

It didn't help either in my situation.

Some people report that moving to a 2xxx or 4xxx resolved the issue. Others with 2xxx and 4xxx are still affected.

I tried some of the solutions suggested (clearing the display device cache, removing the nVidia audio driver and using the Microsoft one instead), none of this helped.

So I've decided to put my 1080ti back momentarily to see if it fixes the Atmos dropouts issue (with MC31 as the issue is still present with MC29 when using the 3090).

I'll report back whenever I have anything conclusive.

[JimH]

Is there any NVIDIA control program running in the background?  Can you shut it down or tell it not to start?

Did you check Windows power settings?

[JimH]

Manni,
Thanks for posting that and for the link to reddit.

[htnut]

The thread title says [Solved].  I read the entire thread, and this issue does not appear to be solved.  Did I miss something or should the thread title be revised?

I am encountering the dropped audio every 10-30 minutes on some (maybe not all) Atmos titles, since upgrading to MC31.  Audio drops out for about 1 full second sometimes with a frame drop (or a few).  Happens in menu mode or not.  Does not happen with Zoom Player configured similarly.

[Manni]

The thread title says [Solved].  I read the entire thread, and this issue does not appear to be solved.  Did I miss something or should the thread title be revised?

I am encountering the dropped audio every 10-30 minutes on some (maybe not all) Atmos titles, since upgrading to MC31.  Audio drops out for about 1 full second sometimes with a frame drop (or a few).  Happens in menu mode or not.  Does not happen with Zoom Player configured similarly.

The thread was marked solved when I mistakenly reported it solved, and left that way. Solved should indeed be removed.

Please could you list your hardware (including audio/video chain) and software details? Also what's the JRiver version you were using previously that didn't show the issue?

This is exactly the issue I was experiencing with my 3090. It seems to be resolved with the 1080ti, but I haven’t watched enough films to be definitive.

Note that most menus are not sending Atmos sound, so if this happens even with menus it's not Atmos specific. I don't know of any title that sends Atmos sound for menus. If you find one or more, please list the title(s) and edition (UHD or bluray and country). All my audio dropouts happen only with the main title, while the AVR is reporting Atmos decoding.

[JimH]

The thread was marked solved when I mistakenly reported it solved, and left that way. Solved should indeed be removed.

This is exactly the issue I was experiencing with my 3090. It seems to be resolved with the 1080ti, but I haven’t watched enough films to be definitive.

That looks like a driver problem and so I posted it here:
https://yabb.jriver.com/interact/index.php/topic,24031.msg947226.html#msg947226

"Solved" sometimes means we know the cause and it's not JRiver.

[jmone]

Note that most menus are not sending Atmos sound, so if this happens even with menus it's not Atmos specific. I don't know of any title that sends Atmos sound for menus. If you find one or more, please list the title(s) and edition (UHD or bluray and country). All my audio dropouts happen only with the main title, while the AVR is reporting Atmos decoding.

I think HTNUT is referring to the playback method.  In MC, you can use "Menu" playback (where you get the full disc menu for selection of Audio, Subs etc) or "Title" playback (where it just plays the "main" MPLS), rather than suggesting drop outs occurring when the menu is being displayed. 

[htnut]

jmone, you are correct. 

[htnut]

The thread was marked solved when I mistakenly reported it solved, and left that way. Solved should indeed be removed.

Please could you list your hardware (including audio/video chain) and software details? Also what's the JRiver version you were using previously that didn't show the issue?

This is exactly the issue I was experiencing with my 3090. It seems to be resolved with the 1080ti, but I haven’t watched enough films to be definitive.

Note that most menus are not sending Atmos sound, so if this happens even with menus it's not Atmos specific. I don't know of any title that sends Atmos sound for menus. If you find one or more, please list the title(s) and edition (UHD or bluray and country). All my audio dropouts happen only with the main title, while the AVR is reporting Atmos decoding.

This machine is an i3 with Iris integrated graphics.  HDMI to Denon AVR which reports Atmos using the (newly “fixed”) DirectSound.  I didn’t try going back to WASAPI but it seems there are multiple reports here that this same issue is occurring when bitstreamed over WASPI, too. I formerly used MC30.

[JimH]

Please also try WASAPI.