INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: Movieman on July 12, 2023, 06:39:42 pm
-
I am hearing audio dropouts on Dolby Atmos tracks when bitstreaming, accompanied by frame drops incrementing by 3. The audio dropouts vary from a fraction of a second in length to about a second.
The first of the attached files was a screen capture taken before the audio drop, the second after the audio drop.
It may be triggered by a preceding chapter step or skip caused by moving the slider, although the cause and the effect are not usually close in time. IOW, the drops can occur anywhere from maybe 1 to 10 minutes after the triggering event and can continue throughout the remainder of the title at random without any further triggering events. They are also not repeatable in time between different playback occurrences of the same title.
Based on seeing a similar issue on that other player which will go nameless here and at least one other post I have linked here, it's possible that either ffmpeg, or libplacebo's use of ffmpeg could be the root cause.
Other links to the issue....
https://trac.ffmpeg.org/ticket/9569 (https://trac.ffmpeg.org/ticket/9569)
https://trac.ffmpeg.org/ticket/10466 (https://trac.ffmpeg.org/ticket/10466)
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200412195626.9090-1-anssi.hannula@iki.fi/ (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200412195626.9090-1-anssi.hannula@iki.fi/)
The 3rd and 4th files are two dump files from that "unnamed" player which possible might shed some light on the issue.
Atmos_audio_drop_seeks_chapters.txt is the result of doing a couple of chapter skips and seeks and then ending play after a couple of drops.
Atmos_audio_drops_no_seeks_no_chapters.txt is the result of starting playback and letting the title play to completion with no manual intervention.
Notice that at one point in the first file the detected frame rate goes to 23.953
[ 14.091][v][vo/gpu-next/libplacebo] Estimated source FPS: 23.953, display FPS: 23.953
There are also error messages related to Atmos from ffmpeg that are referenced in the dump files and the links posted above.
[ 15.234][w][ffmpeg] spdif: Unusual frame timing: 20024 => 10387, 40 samples/frame is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[ 15.234][w][ffmpeg] spdif: If you want to help, upload a sample of this file to https://streams.videolan.org/upload/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
The third URL I posted above refers to a patch to that issue.
One other behavior I noticed in JRiver is that as a result of a chapter skip both the dropped and repeated frame counts increment by a relatively large amount for each operation.
Additional Info: Just watched the first 30 minutes of Star Trek TMP Directors Cut. Used the disc menu option in JR. Two brief dropouts, frame drops increased +3 for each one.
I am on 31.0.33.
Is there any way to enable a debug log similar to what I attached like unnamed does?
-
Hi Vern,
What's your connection setup from your PC to the amp / PJ including any splitters / edid devices etc?
How are you changing the refresh rates? (eg are you using Tools --> Options --> Video --> Display Settings --> Display Settings automatic change mode ?)
There is also a log option (JRVR Options --> Advanced --> Debugging --> Log Frame Timing) that Hendrik as used in the past to identify and fix similar issues.... but it has been rock solid since. Note: This log gets very big very quickly, so turn it on, capture the issue then turn it back off.
To narrow it down is it only the ATMOS, or only when bitstreaming? eg you could try turning OFF bitstreaming the audio (Tools --> Options --> Audio --> Settings --> Bitstreaming = "None") then enabling "Video Clock" (Tools --> Options --> Video --> Videoclock) and see if it goes away.
-
The video renderer is not really related to the audio timing - its the other way around if anything, if an audio glitch happens, the audio renderer updates the reference clock, causing the video renderer to drop a frame to stay in sync.
Note that we don't use any external libraries for TrueHD bitstreaming, its all custom, not based on ffmpeg. It fully supports burst gaps as described above, which I implemented years ago when UHD Atmos discs became common that exceeded the bandwidth limit that made these bursts necessary.
I have added some refinements to bitstream timings that may help with TrueHD, if the cause is what I think it might be. TrueHD is rather special among the bitstreamed formats, as its variable length, since the bitrate can swing wildly.
If there is a bitrate peak thats too high, it could potentially result in the audio renderer thinking its out of sync, when its really not. So by better accounting for the peaks, the timing remains more consistent.
-
Hi Vern,
What's your connection setup from your PC to the amp / PJ including any splitters / edid devices etc?
Direct HDMI
How are you changing the refresh rates? (eg are you using Tools --> Options --> Video --> Display Settings --> Display Settings automatic change mode ?)
PC set to 23.976. Source at 23.976.
There is also a log option (JRVR Options --> Advanced --> Debugging --> Log Frame Timing) that Hendrik as used in the past to identify and fix similar issues.... but it has been rock solid since. Note: This log gets very big very quickly, so turn it on, capture the issue then turn it back off.
To narrow it down is it only the ATMOS, or only when bitstreaming? eg you could try turning OFF bitstreaming the audio (Tools --> Options --> Audio --> Settings --> Bitstreaming = "None") then enabling "Video Clock" (Tools --> Options --> Video --> Videoclock) and see if it goes away.
Only ATMOS, doesn't happen with any other type of track I don't use videoclock. Only fails when bitstreaming. Issue is new with MC31.
-
I've been having similar audio dropouts and a/v sync issues recently, it hasn't been going on for long enough to narrow down to specific codecs in my case, but I can trigger it on almost anything by seeking and pausing a few times. Could be related, I will test fixes in beta tonight.
-
The video renderer is not really related to the audio timing - its the other way around if anything, if an audio glitch happens, the audio renderer updates the reference clock, causing the video renderer to drop a frame to stay in sync.
Note that we don't use any external libraries for TrueHD bitstreaming, its all custom, not based on ffmpeg. It fully supports burst gaps as described above, which I implemented years ago when UHD Atmos discs became common that exceeded the bandwidth limit that made these bursts necessary.
I have added some refinements to bitstream timings that may help with TrueHD, if the cause is what I think it might be. TrueHD is rather special among the bitstreamed formats, as its variable length, since the bitrate can swing wildly.
If there is a bitrate peak thats too high, it could potentially result in the audio renderer thinking its out of sync, when its really not. So by better accounting for the peaks, the timing remains more consistent.
Please note, I had a typo I just corrected 77.1 should be 77.2 Also added an additional observation at the end.
Thanks for the info.
OK, some additional info from a session in the HT this AM.
FWIW, the audio dropouts on JRiver 31.0.33 occurred with both JRVR and the MadVR Red October HQ.
Just to verify, I tried using Zoom Player + MadVR which is a 32 bit app that I have used for years with no issues Was very surprised to see the same audio dropout problem there, where it was never present before.
The only recent change on the PC was installing LAV Filters version 77.2 to match with the version supplied with JRiver. So basic PD, right - what has recently changed?
Downloaded, installed, and registered LAV Filters 76.1, and, like magic, no more audio drops with Atmos on Zoom Player. However, no more tone mapping, either.
OK, I'll try the same with JRiver.... copied the 64 bit 76.1 into C:\Users\HTUser\AppData\Roaming\J River\Media Center 31\Plugins\lav64, re-registered with regsrver32, with the results being no more tone mapping, but still audio dropouts.
Not sure if this is pertinent to the issue, but in the process of comparing ZP and JRiver, both with MadVR, I noticed another anomaly.
ZP MadVR states
display 23.97556 Hz
composition rate 23.976 Hz
clock deviation -0.00086%
smooth motion off
1 Frame Drop Every 1.09 hours
JRiverMadVR states
display 23.97554 Hz
composition rate 23.976 Hz
clock deviation -0.007771%
smooth motion off
1 Frame Drop Every 7.16 minutes
JRiver's calculation always indicates a shorter time between drops.
I suspect somebodies math is off here, but I'm not sure who's.
Also with 77.2 the frame drop timing is extremely inconsistent. In one instance I saw it change from around 1.x minutes to 20 some hours and back to 3.x minutes. This preceded an audio drop.
-
Dup - Sorry
-
I've been having similar audio dropouts and a/v sync issues recently, it hasn't been going on for long enough to narrow down to specific codecs in my case, but I can trigger it on almost anything by seeking and pausing a few times. Could be related, I will test fixes in beta tonight.
This could be a clue......
The only recent change on the PC was installing LAV Filters version 77.1 to match with the version supplied with JRiver. So basic PD, right - what has recently changed?
Downloaded, installed, and registered LAV Filters 76.1, and, like magic, no more audio drops with Atmos on Zoom Player.
-
No need to collect clues. I have personally written all the code involved, and know what's going in.
It'll be fixed for MC in the next update, and I'll apply a workaround for audio rendered that don't fully understand TrueHD in LAV Audio in a future update as well.
-
No need to collect clues. I have personally written all the code involved, and know what's going in.
It'll be fixed for MC in the next update, and I'll apply a workaround for audio rendered that don't fully understand TrueHD in LAV Audio in a future update as well.
Great. Thank you, appreciate the effort. :)
-
No need to collect clues. I have personally written all the code involved, and know what's going in.
It'll be fixed for MC in the next update, and I'll apply a workaround for audio rendered that don't fully understand TrueHD in LAV Audio in a future update as well.
Will that be picked up by ffmpeg as well? Or are the two even remotely related?
-
There is no shared code between this and ffmpeg, so no.
-
To take advantage of fixes that are to be implemented, should we turn on or off any features?
-
I just have to chirp in here also as Ive been having random audio dropouts for the past few weeks and trying to nail it down.....
I thought it was due to a new firmware update I did two weeks ago for my McIntosh MX160 pre pro. I was blaming it and spoke to a number of people about the issue. Last night we watched an Atmos 2 hour film and I had 7 random auto droputs at least 1 sec long throughout the movie, it was embarrassing as we had friends over.
This morning I did a rollback to the older firmware on the MX160 and played ther same film again for 1 hour, I had less dropouts but still had 2. So I now realise the fault isnt totally from the new firmware on the MX160. Something within MC31 from one of the updates I think is causing the dropouts on atmos films for me. I dont play that many atmos films and always bitstream everything so maybe thats why I havent picked it up sooner.
I hope the new update thats coming to MC31 will fix my dropouts.
-
You should be able to test a fix that Hendrik has already applied in MC31.0.34 (once it is on the main board).
-
You should be able to test a fix that Hendrik has already applied in MC31.0.34 (once it is on the main board).
Great I cant wait!
-
The updated version is on the top of the board - https://yabb.jriver.com/interact/index.php/topic,136545.0.html
-
No joy.....
The audio dropouts are still present. Was watching the statistics at the time, 2 dropped video frames, about a 2 second audio dropout, then one more dropped video frame.
Data on the failure: Disc title: UHD Mamma Mia Here We Go Again
Attached is the frame log - failure at frame 16767. On several runs, it always occurs at roughly the same time, rather than being totally random. I didn't go past this drop so I can't give you more info on subsequent drops.
I took an extract from the file using the ffmpeg command
D:\Apps\ffmpeg\ffmpeg -ss 00:11:00 -to 00:14:00 -i "F:\BDMV\STREAM\00011.m2ts" -map 0 -c copy "MMHWGA2.mkv"
and it plays clean with no drops, so it's not something in the m2ts file. I also added the zip of the frame log from the extracted mkv.
-
I just ran the same atmos film for 30mins and never had a dropout this time, I cant say for sure 100% its gone as I didnt have anymore time to test. However I will try and watch another film till the end and report back.....
-
No joy.....
The audio dropouts are still present. Was watching the statistics at the time, 2 dropped video frames, about a 2 second audio dropout, then one more dropped video frame.
Data on the failure: Disc title: UHD Mamma Mia Here We Go Again
Attached is the frame log - failure at frame 16767. On several runs, it always occurs at roughly the same time, rather than being totally random. I didn't go past this drop so I can't give you more info on subsequent drops.
I took an extract from the file using the ffmpeg command
D:\Apps\ffmpeg\ffmpeg -ss 00:11:00 -to 00:14:00 -i "F:\BDMV\STREAM\00011.m2ts" -map 0 -c copy "MMHWGA2.mkv"
and it plays clean with no drops, so it's not something in the m2ts file. I also added the zip of the frame log from the extracted mkv.
I was having these same issues recently, it turned out to be caused by a bad Intel GPU driver update. I clean installed the same version (31.0.101.2115, latest) and my audio dropouts and lip sync issues went away. Might be worth a try.
-
I was having these same issues recently, it turned out to be caused by a bad Intel GPU driver update. I clean installed the same version (31.0.101.2115, latest) and my audio dropouts and lip sync issues went away. Might be worth a try.
Thanks for the suggestion, but for me, it's happening on multiple systems with different drivers and different Nvidia cards.
My other players don't have this issue with LAV Filters 0.76.1, but do when they are updated to 0.77.X
JRiver 30 doesn't have the issue. No lip sync issues here, either. Also it is specific to Dolby Atmos tracks.
I also don't allow my Win 10 systems to update HW drivers.
-
The last changes to TrueHD bitstreaming were actually in LAV 0.76, bitstreaming was not changed in 0.77 at all. MC30 was also using LAV 0.77.2 already, which you report as previously "good". Your information are a bit inconclusive.
I can personally attest to the latest changes fixing some drop-outs, as well as comments from another user that it was fixed for them.
As I have also previously said, this is an audio issue. Video logs don't mean anything to the issue. Video frames are dropped as a consequence of audio issues, not the other way around.
A normal MC log may indicate something, but it usually only tells what happens, not why.
Since you already setup a dedicated thread on this topic, just keep using this one as well, no need to split the discussion.
-
This is by no means definitive but I had been experiencing at least one audio dropout issue per film, usually more like two.
Last night I did not have any throughout an entire film with the current update.
-
The kind of drops it fixed would have happened around the same time in a movie too, and not randomly.
-
Thanks for the suggestion, but for me, it's happening on multiple systems with different drivers and different Nvidia cards.
That still doesn't rule out an NVIDIA driver problem.
-
Yes, or more likely a Windows update issue since in my case the dropouts arose sporadically several months after initially installing the driver. It's possible that a recent Windows update might be borking driver installations, which in my case was rectified by a clean driver installation (IIRC that option also exists in the nvidia driver installer, why would it be there if not for times such as these?). I'd at least give it a shot on one system.
-
The last changes to TrueHD bitstreaming were actually in LAV 0.76, bitstreaming was not changed in 0.77 at all. MC30 was also using LAV 0.77.2 already, which you report as previously "good". Your information are a bit inconclusive.
I can personally attest to the latest changes fixing some drop-outs, as well as comments from another user that it was fixed for them.
As I have also previously said, this is an audio issue. Video logs don't mean anything to the issue. Video frames are dropped as a consequence of audio issues, not the other way around.
A normal MC log may indicate something, but it usually only tells what happens, not why.
Since you already setup a dedicated thread on this topic, just keep using this one as well, no need to split the discussion.
In the interests of clarity, I spent most of the afternoon re-running several scenarios in my HT.
Some of my past comments were also based on experience with my office system, which uses a different receiver and display, so there may some have been cause for confusion.
The environment:
JVC RS3100
Denon AVR-4500H
HTPC Intel i7-6700@3.4GHz quad core CPU
Win 10 Pro 22H2
NVidia RTX 3060 Ti PCI Express x16 gen 3 Direct3D 12.1
NVidia drivers 516.94 (installed when the PC was upgraded to Win 10 in Jan 2023)
All equipment is sourced from a single 20 amp duplex receptacle and shares a common ground.
I have never experienced any audio dropouts with any Directshow based players in my HT until Beta 31, however I have experienced a few in the past with beta versions of a few ffmpeg based players.
The system(s) (3 PCs - one for 2K, one for 3D, & one for 4K) in the HT have always been 100% stable, no HDMI issues with negotiation between devices ever.
OK the results - in columns -player software- - player software version - - LAV Filters version - - Audio Dropouts -
JRiver (MadVR) 30.0.96 0.8.0 No
JRiver (JRVR) 31.0.34 0.8.0 Yes
JRiver (MadVR) 31.0.34 0.8.0 Yes
JRiver (JRVR) 31.0.34 0.76.1 Yes
JRiver (JRVR) 31.0.34 0.77.2-2 Yes
Zoom Player (MadVR) 17.2 (32 bit) 0.76.1 No
Zoom Player (MadVR) 17.2 (32 bit) 0.77.2-2 No
MPV (ffmpeg) mpv-x86_64-20230716-git No
*Note, I'm calling the latest LAV Filters code that is downloaded and installed with new installs of JRiver *0.8.0*, since I don't know what to call it otherwise.
Since I had to re-install JRiver 30, it also got the latest LAV Filters code downloaded the first time I initiated playback.
I don't know how else I can explain what I am experiencing, particularly since my 3 daily driver players don't have these issues.
I do hope these issues do get resolved (sooner rather than later). I'm certainly willing to participate in further testing / debugging to help.
-
Make sure WindowDefender is configured and no other antivirus is in use.
-
Since it seems to have started with MC31 for you, maybe you could try to narrow it down further?
Here is all public MC31 versions:
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310002-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310005-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310008-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310009-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310010-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310017-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310021-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310023-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310025-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310029-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310032-x64.exe
https://files.jriver-cdn.com/mediacenter/channels/v31/latest/MediaCenter310034-x64.exe
You don't have to try every single one of them, but maybe start in the middle, and if its happening there, go to earlier versions, if not, go to later ones.
Don't change any other variables while testing.
I don't see anything obvious that would have changed since MC30, its not been that long yet.
A log from the latest MC might also help (normal MC log, not the video log)
-
Ok, starting the process.
Here is the log from the 31.0.36 drop.
We're on the right track, no drops 0n 31.0.5
Proceeding to half split.....
good on 31.0.21
good on 31.0.25
-
Which output device have you selected in MC configuration?
You should probably be using WASAPI when bitstreaming. From the log I think you are using the default directsound device, which is not recommended - and actually I don't think it even supported bitstreaming TrueHD until recently, when I fixed a bug in there.
-
Using WASAPI, other options won't connect.
-
The log does not show that, so maybe double check that?
What you should be seeing when WASAPI is in use is something like this in the log:
0029929: 23648: Playback: COutputPluginAudioRenderer::Open: Opening output plugin
0029929: 4932: Playback: CWASAPIPlugin::Open: Start
0029930: 4932: Playback: CWASAPIPlugin::Open: Device: ; Exclusive: 1; Event style: 1, afOutput: 48 kHz 64bit 2ch
0029930: 21256: Playback: CWASAPIPlugin::Thread: Start
0029930: 21256: Playback: CWASAPIPlugin::Thread: Starting WASAPI
0029930: 21256: Playback: CWASAPIPlugin::StartWASAPI: Start
0029961: 21256: Playback: CWASAPIPlugin::StartWASAPI: Started WASAPI: 4800 buffer blocks, 400,0000 internal buffer ms, 99 fill sleep ms, output format 48 kHz 24bit (padded) 2ch
0029961: 21256: Playback: CWASAPIPlugin::StartWASAPI: Success opening device
0029961: 21256: Playback: CWASAPIPlugin::StartWASAPI: Finish (31 ms)
0029961: 21256: Playback: CWASAPIPlugin::Thread: Boosting priority
0029962: 21256: Playback: CWASAPIPlugin::Thread: Prerolling silence
0029962: 21256: Playback: CWASAPIPlugin::Thread: Starting
0029971: 4932: Playback: CWASAPIPlugin::Open: Finish (42 ms)
0029972: 23648: Playback: COutputPluginAudioRenderer::Open: Output Plugin Feeder opened
But your log has nothing of CWASAPIPlugin in it, indicating to me that its not WASAPI, but likely DirectSound, which does not log its startup for various reasons.
-
I just checked. WASAPI is selected. I'm taking logs of all my test runs. I suppose it's possible, but normally I get an error message when I start playback if I don't have WASAPI selected.
-
Can you take a screenshot of the Audio Path while playing?
-
Which log are you looking at?
-
I'm looking at the log from 36 you posted where you were having issues.
Audio Path is the cogwheel in the top bar (blue here), and should look like this: (I'm not bitstreaming, not setup on this system)
(https://i.imgur.com/RDW8pL7.jpg)
-
Yep, confirm that. Re-running 36 with WASAPI selected. Interesting, if that's it because my receiver has always confirmed Dolby Atmos - TrueHD.
-
Yep, That's it. MC30's behavior is to fail with a "Something Went wrong with playback" message when Default audio device is selected.
MC31 doesn't complain, but has dropout issues during playback.
Very much my bad, for not recognizing this. I apologize.
A suggestion: To idiot proof this, you may want to remove the "Default audio device" selection from the audio settings or somehow flag it as unusable when bit streaming is selected.
The "Bitstreaming None (recommended)" hardly seems to apply in today's world of object oriented audio and home theatre.
Or, possibly, if there is a way, address the issue with ATMOS when "Default audio device" is selected, although I don't think that's worth the effort.
Again, thanks for taking the time to help me understand the issue.
-
I'm looking at the log from 36 you posted where you were having issues.
Audio Path is the cogwheel in the top bar (blue here), and should look like this: (I'm not bitstreaming, not setup on this system)
(https://i.imgur.com/RDW8pL7.jpg)
Got it. Since it's a HT, I always run full screen mode.
-
Glad you got to the bottom of it! and long live WASAPI (best feature added in Vista IMO) :)
A suggestion: To idiot proof this, you may want to remove the "Default audio device" selection from the audio settings or somehow flag it as unusable when bit streaming is selected.
FWIW, "Default audio device" is just "use the default audio device you have set a in Windows"...and this makes sense to me as the Default setting in MC for new (and probably most) users. Also (pending on what the audio device is), it is perfectly capable of being set to Bitstreaming (or Not) in MC.
The "Bitstreaming None (recommended)" hardly seems to apply in today's world of object oriented audio and home theatre.
Actually, my preference would be to only bitstream Object Oriented audio and decode the rest (so as to use VideoClock where you can). Also, for those without ATMOS setups, then decoding everything will be better in conjunction with Videclock as it reduces/removes dropped video frames caused by audio clock drift.
At present in MC we can already select to only bitstream selected "brands" but not just the Object Oriented subset.
-
I looked at the DirectSound output and it was missing a flag for more accurate position tracking, seemingly because this was not supported on (very) old versions of Windows. But we no longer support those, sooooo
Hopefully this should make DirectSound overall more reliable. Certainly shows much more stable numbers in my testing.
-
I looked at the DirectSound output and it was missing a flag for more accurate position tracking, seemingly because this was not supported on (very) old versions of Windows. But we no longer support those, sooooo
Hopefully this should make DirectSound overall more reliable. Certainly shows much more stable numbers in my testing.
Thanks again.
Glad there was something there to change so it wasn't a totally futile exercise.
I'll run a test on it when the next release hits. Still not sure how / when I failed to notice that setting wasn't set properly when I installed 31, but I suspect the error on the older versions always prompted me to set it properly for them.
One other thing, if you missed my previous mention:
On the video settings, the sliders could use a little more granularity, and the numeric values appear to be borked (garbage, or numbers that don't change when the sliders are moved). I noticed that when I was trying to get consistent black / white clipping results across several players this evening.
-
I still have audio dropouts on atmos films, just tested one tonight and after 9 mins it dropped out, I stopped and turned off my HT. I just dont know when this first started but it never used to happen.....
-
Murray, you might have to:
- Turn on logging
- Play the video till the drop out occurs
- Stop and post the log here
- Turn off logging
-
Glad you got to the bottom of it! and long live WASAPI (best feature added in Vista IMO) :)
FWIW, "Default audio device" is just "use the default audio device you have set a in Windows"...and this makes sense to me as the Default setting in MC for new (and probably most) users. Also (pending on what the audio device is), it is perfectly capable of being set to Bitstreaming (or Not) in MC.
Actually, my preference would be to only bitstream Object Oriented audio and decode the rest (so as to use VideoClock where you can). Also, for those without ATMOS setups, then decoding everything will be better in conjunction with Videclock as it reduces/removes dropped video frames caused by audio clock drift.
At present in MC we can already select to only bitstream selected "brands" but not just the Object Oriented subset.
Unfortunately, the issue with avoiding bitstreaming is that it removes the ability of the more high(ish) end receivers to apply processing that is specifically tailored to the room acoustics and the speaker locations. See attachment 1, (which is actually a poor example as it doesn't do justice to OO codecs, but was the only photo I had available).
Still, it's good to have the options. I have a ton of audio files on my JRiver server, which is upstairs and connected to my home gig ethernet, many of which are high bit rate/depth flac files. Heos direct to receiver works well for me.
Dropped video frames are pretty much a non-issue to me as an NVidia user, as it's possible to tune the video card settings to minimize drops or repeats. Granted, it's not perfect, as the clock can and does drift (and it's not applicable to Joe user, but then Joe user probably doesn't have a dedicated HT either). See attachment 2 & 3.
I am also very allergic to the 3/2 pulldown cadence and always run my displays at the source media refresh rate.
But I digress.....
-
Unfortunately, the issue with avoiding bitstreaming is that it removes the ability of the more high(ish) end receivers to apply processing that is specifically tailored to the room acoustics and the speaker locations.
Are you aware of convolution and JRiver's support for it?
https://wiki.jriver.com/index.php/Convolution
-
Are you aware of convolution and JRiver's support for it?
https://wiki.jriver.com/index.php/Convolution
Yes, but it's just not as simple a solution as letting the AVR handle it which it does with pretty much no user involvement after the initial speaker location definition and calibration run.
Although it sounds like Convolution is probably more customizable.
-
You should really complain to the AVR maker if their room correction cannot be applied to decoded audio input, for the amount these things cost.
Audio is audio, such a limitation is entirely artificial.
-
Murray, you might have to:
- Turn on logging
- Play the video till the drop out occurs
- Stop and post the log here
- Turn off logging
I have the info now on the audio dropouts Im strill having on Atmos films.
The film I played last night first dropped out at 9mins then I stopped.
Today that same film dropped out at 13mins then 3 or 4 secs after it dropped out a second time, I stopped the film then.
The other atmos film I played the other night before the last update dropped out something like 7 times throughout a 2 hr film.
Here is the log from today.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
Then I have no idea what is up. You're going to need to log it I guess!
-
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.
-
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.
-
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?
-
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!
-
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.
-
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
-
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.
-
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.
-
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.
-
Don't replace any plug-ins JRiver uses for video. Don't use them for any other application. Either could cause problems.
-
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?
-
Don't do anything for JRiver's use. JRiver will take care of itself.
-
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?
-
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.
-
JRiver needs to use a more recent madvr then
There's no problem using beta madvr versions (whether supported or not)
-
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.
-
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).
-
Call us conservative. We update plug-ins only when there is a good reason.
Do NOT change them for any reason.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
-
Check your Windows power settings.
-
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.
-
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?
-
Manni,
Thanks for posting that and for the link to reddit.
-
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 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.
-
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.
-
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.
-
jmone, you are correct.
-
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.
-
Please also try WASAPI.
-
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.
@JimH, please could you share how you know that?
The latest nVidia driver supposedly fixes the Atmos dropout bug with the 3000 series and a HDMI 2.1 AVR, but:
1) I reported that the latest nVidia driver doesn't resolve my issue with the 3090 when using JRiver
2) I reported that many nVidia users with 2000, 3000 and 4000 series still had the issue (with or without JRiver)
3) I reported that I only experienced this issue with JRiver, never with MPC-BE or MPC-HC
4) You have another user who has the same issue but doesn't use nVidia and has also reported that he only experienced the dropouts with JRiver
5) A 1080ti using the same driver has no Atmos dropouts with JRiver (I played five full films with Atmos, not a single Atmos audi dropout).
@HTNut
Thanks for the information. It looks like our issue might have different causes, because in my case the GPU seem to be clearly a factor. I only have the issue with the 3090 and not with the 1080ti, using the same driver (latest studio) after a clean install with DRU.
I had the issue with MC29 and MC30 as well as MC30, so that's another difference if you were not experiencing it with MC30.
Worth trying WASAPI indeed, it might correct your issue.
I'm not putting the 3090 back to do further tests with other software, as the issue is apparently resolved and not connected to JRiver.
As far as I'm concerned though, it's not resolved given that I only found a workaround in reverting to my previous GPU.
-
Manni,
It's only my opinion.
If it works with an older card, it is probably the driver.
We're still collecting information. There's not much certainty if it's not a common problem.
-
Manni,
It's only my opinion.
If it works with an older card, it is probably the driver.
We're still collecting information. There's not much certainty if it's not a common problem.
No, it's not a driver problem, it's a hardware problem in my case (not in HTnut's case of course as we don't have the same GPU).
All the information about the Atmos dropout on Ampere (3000 series) points to an unfixable hardware issue. It looks like nVidia declared the bug resolved in a recent driver after having put it in their known bug list to try to avoid a class action. They realised it couldn't be fixed (at least not for all) after a year, so they declared it fixed.
Anyway, it's not a common problem and I guess I'll just have to use the workaround I found for now, which is to use the 1080ti (with the exact same driver I was using with the 3090).
-
Please also try WASAPI.
Jim and Hendrik,
No dropouts in WASAPI mode. But, my enthusiasm for MC31 is due to DirectSound bitstreaming being "fixed". In my application I really need shared mode bitstreaming.
I also tested Zoom Player using DirectSound bitstreaming and NO dropouts, so this problem is unique to MC (or some setting/configuration I need to change).
Can you suggest some troubleshooting steps I can try? So far I've used three titles: John Wick 4 UHD (Atomss); Blinded by the Light BD (Atmos); and Fargo BD (DTS-HD). Machine is i3 with Iris integrated graphics, HDMI to a Denon AVR.
-
Which exact version of MC31 are you actually using?
-
Which exact version of MC31 are you actually using?
31.0.36 (64 bit)
-
Update to 31.0.41 from here:
https://yabb.jriver.com/interact/index.php/topic,136686.0.html
I improved the timing of DirectSound output in 31.0.37.
-
Update to 31.0.41 from here:
https://yabb.jriver.com/interact/index.php/topic,136686.0.html
I improved the timing of DirectSound output in 31.0.37.
Just noticed that after I posted my reply :) Thank you. I'll give the lastest v.41 a go tonight.
-
Update to 31.0.41 from here:
https://yabb.jriver.com/interact/index.php/topic,136686.0.html
I improved the timing of DirectSound output in 31.0.37.
Unfortunately the audio dropouts continue. We watched both The Equalizer (DTS-HD) and La La Land (Atmos). To troubleshoot, I tried adjusting the "buffering" setting very low and very high (in device settings) and also changed "default channels" to "all channels". Didn't make a difference. Dropouts every 10-20 minutes typically but it seems to vary.
-
Unfortunately the audio dropouts continue. We watched both The Equalizer (DTS-HD) and La La Land (Atmos). To troubleshoot, I tried adjusting the "buffering" setting very low and very high (in device settings) and also changed "default channels" to "all channels". Didn't make a difference. Dropouts every 10-20 minutes typically but it seems to vary.
Hendrik, any other suggestions I can try to solve the DirectSound dropouts? Reminder, the same config (MadVR, LAV, DirectSound bitstreaming) in Zoom Player does not encounter these dropouts.
-
Update to 31.0.41 from here:
https://yabb.jriver.com/interact/index.php/topic,136686.0.html
I improved the timing of DirectSound output in 31.0.37.
Hendrik, is there continued research being done on this, or another troubleshooting method I should employ?
-
I did extended testing with the 1080ti and I can confirm that the 1080ti works fine with the Denon X8500HA, but only in WASAPI. I get Atmos audio dropouts in Direct Sound even with the 1080ti.
I wanted to do one last attempt with the 3090 as it annoyed me to have to use my old 1080ti, which is slower and uses more power.
I can confirm that with the same settings / drivers as the 1080ti, I get Atmos audio drops with the 3090 both in WASAPI and Direct Sound.
WHAT DIDN'T WORK:
As the issue seems to be connected to the HDMI 2.1 connection, I tried to move the 3090 to a HDMI 2.0 input on the AVR and limit the AVR bandwidth to HDMI 2.0 (18gbps) as well (HDMI Enhanced 4K instead of 8K). That didn't help.
I also took the HD Fury VROOM out of the chain, to make sure that it wasn't involved, and as expected it wasn't. Given that it's after the AVR (between the AVR and the JVC), it would have been very surprising if it could have an impact as it wasn't part of the audio chain.
I also tried to change the resolution to 16/24bits 192khz in the windows sound settings, that didn't help.
I tried to replace the nVidia HD Audio driver with the MS defaut HD Audio driver, didn't help either.
I clean installed (after DDU) the latest nVidia studio driver (536.99 DCH). That made no difference.
In the end though, I did manage to get it to work perfectly :) [EDIT: Unfortunately the drop outs came back, see my post further down].
WHAT WORKED:
First of all, against the general advice to use 1-3 frames in advance for madVR rendering with an Ampere GPU, I use 8 (windowed fullscreen in Win 11). This limits the number of video frames dropped / glitches to 1-2 per 2 hour movies. I'm set to RGB Full 8bits at 60p and RGB Full 12bits at 23p (as I'm limited to HDMI 2.0 bandwidth on the input I currently use on the X8500HA).
Note that I use D3D11 copyback (force to the 3090 in LAV video) so that I can get black bar detection in madVR, but native (automatic) works fine too.
I can use the normal power setting in the nVidia control panel (Managed 3D settings) as it doesn't seem to make a difference, but I kept vertical sync on as it eliminates the glitches/frame drop/repeats that you get otherwise.
What made the biggest difference (as far as I can tell) specifically re the Dolby Atmos audio dropouts is to select Dolby Atmos in the sound settings instead of 7.1. I had always used 7.1 previously (as I'm bitstreaming anyway and I don't use Atmos in games), without any problem, but for some reason the 7.1 setting seems to be what causes the Atmos Audio drop outs here with the 3090. I also installed and selected once the DTS:X sound format, as it's supposed to help. It might have as well. [EDIT: This was probably a coincidence and most likely has no effects on Atmos drop out, the setting has no effect when bitstreaming film content as it's probably only relevant with games, even stereo works fine with Atmos]
It took me quite a while to recommission this HTPC and get it at the level I wanted it to be, but given that it's also used as a gaming and editing PC, it was well worth spending the extra time to get the 3090 back in. I've played multiple Atmos titles, including very long ones (Lord of the Rings trilogy) with zero Atmos audio drop outs and only a few video frames dropped (which I consider as normal over a few hours), so I'm positive this is fixed this time. [No idea why I was able to play a few long films without Atmos audio drops or why they came back with the 3090].
Once I had verified that all was working fine, I undervolted the GPU using MSI Afterburner and the CPU (AMD Ryzen 5950X in ASRock X570 Creator) using the PBO2 in my BIOS to optimise power use, and it's all perfectly stable (and less hot), using less power than the 1080ti both in idle and during 4K UHD Playback. [EDIT: When the Atmos drop outs came back, I reverted back to no undervolting for the GPU and restored the pre-undervolting for the CPU and the Atmos drop outs were still there, so these changes are not the reason].
I haven't tested if this would work on the HDMI 2.1 input, as I prefer to use the HDMI 2.0 input for HTPC (I can't route the HDMI 2.1 input to Zone 2, which is what I use for my Sony HDMI headphones). I suspect it would work.
My GPU is a Zotac 3090 Trinity with 24GB or RAM, in case it matters.
I hope these troubleshooting tips and solutions will help others with the same issue and an nVidia GPU. Good luck everyone, and of course YMMV...
-
With DirectSound, in MC31, all audio formats drop out at least a few times per movie. Not so with the same configuration with ZoomPlayer bitstreaming DirectSound… hoping a fix is coming…
-
The “bug fix” that allows bitstreaming over DirectSound is the single feature I need and would be a reason for me to pay to upgrade to MC31.
But, this issue where bitstreaming drops out from time to time over DirectSound makes it unusable for me. Is this still being investigated/worked on I hope?
-
Unfortunately, my issues with bitstreaming Atmos with MC31 came back with the 3090 (I edited my post above). I tried a 4070 that had the same issue, so I returned it and went back to my good old 1080ti (zero Atmos bitstream issue with it, I'm so glad I didn't sell it when I upgraded to the 3090!).
My understanding is that Nevcairiel (Hendrick) has recently improved Atmos bistream in the latest version of LAV (see https://github.com/Nevcairiel/LAVFilters/commits/master), not sure if it's been updated within JRiver. Apparently, it improves things with 3xxx GPUs but doesn't resolve them entirely. See https://forum.doom9.org/showthread.php?p=1991850#post1991850 for details.
I'm staying with the 1080ti in the HTPC for now (the 3090 went into an E-GPU for my Dell XPS17). I'll make another attempt if anyone reports being able to consistently watch full-length feature films while bistreaming Atmos to a 3xxx through an HDMI 2.1 AVR. Although I believed on a couple of occasions it had gone after changing a few settings, it always came back here, hence why I'm back to the 1080ti.
The [Solved] in the title should really go away if based on any of my previous reports, as this is still a problem here with a 3xxx or 4xxx GPU, though I wouldn't say it's necessarily a JRiver MC problem, it could be a driver/LAV/OS/GPU problem as it's definitely linked to the hardware. Again, same software and same hardware, zero drop outs with 1080ti (WASAPI), drop outs with 3090 or 4070 (after a clean install of the drivers with DDU of course for each GPU swap).
-
Solved means, in my opinion, that's it's not likely to be a JRiver issue.
It seems pretty clear that it's a driver problem.
You could start a new thread on anything you think is probably a JRiver problem. Just link to this thread if you need to.
I hope you can understand why I don't want the team to chase problems that seem to be specific to certain hardware. We're surrounded by companies who have deep pockets but still create driver problems. Take a look at the last five or six problems (and solutions) in this thread, for example: https://yabb.jriver.com/interact/index.php/topic,24031.350.html
-
Solved means, in my opinion, that's it's not likely to be a JRiver issue.
It seems pretty clear that it's a driver problem.
You could start a new thread on anything you think is probably a JRiver problem. Just link to this thread if you need to.
I hope you can understand why I don't want the team to chase problems that seem to be specific to certain hardware. We're surrounded by companies who have deep pockets but still create driver problems. Take a look at the last five or six problems (and solutions) in this thread, for example: https://yabb.jriver.com/interact/index.php/topic,24031.350.html
I respectfully disagree.
LAV Filters is part of JRiver MC and the last version improves this issue (same GPU, same drivers, same OS) without fully resolving it. This shows that this issue is indirectly related to one part of MC.
I have already explained that this wasn't a driver issue, given that the SAME driver (latest at the time, 536.99) works fine with a 1080ti and doesn't with a 3090 or a 4070.
I do agree, however, that it's not necessarily a MC problem, as it could be a LAV issue only with some GPUs, but given that LAV is part of MC it's disingenuous to mark this problem as resolved.
Until someone posts that they have no Atmos drop out issue with MC 31 when bitstreaming, I believe that the [Solved] should be taken out.
However, I think it would be appropriate to either split the thread into solved parts (Murray, for example, apparently had issues because of a HDMI splitter and they went away when he got rid of it), so that part could be marked solved, and others users (HTNut, myself) who are STILL experiencing drop outs when bitstreaming Atmos, one with an Intel iGPU, myself with my 3090 (and a 4070 that I purchased exclusively to test if this issue is still present with the latest gen, as some people have reported). This would allow you to make this thread more specific (i.e. add "with some GPUs") in the title.
I think that those who report the issue as solved with the 4xxx gen (in the wider internet) are talking about something else (gaming for example).
I haven't found a single user who has been able to use a 3xxx (or a 4xxx) when bitstreaming Atmos film content without getting dropouts.
If anyone has, please post here with all your settings (OS, driver, LAV filter, etc).
-
LAV Filters is part of JRiver MC and the last version improves this issue (same GPU, same drivers, same OS) without fully resolving it. This shows that this issue is indirectly related to one part of MC.
The latest LAV change is the same issue that was already fixed in MC before (in a different way). Its a particular bug that would always show up in the same scene in a movie, and on all hardware. That issue was resolved.
It would've similarly caused issues on your 1080Ti if it remained unfixed.
Swapping hardware fixing the remaining issues you have points quite clearly at the hardware or driver being at fault.
-
The latest LAV change is the same issue that was already fixed in MC before (in a different way). Its a particular bug that would always show up in the same scene in a movie, and on all hardware. That issue was resolved.
It would've similarly caused issues on your 1080Ti if it remained unfixed.
Swapping hardware fixing the remaining issues you have points quite clearly at the hardware or driver being at fault.
I’ve now tried three different machines, with different hardware, and get the same result: bitstreaming over DirectSound delivers a dropout (accompanied by a visual hiccup not sure if it’s repeated or dropped frames) at least a few times during a 2 hour movie.
Does not matter if I launch the movie in “menu mode” or “title mode”.
Zoom Player with the same configuration (MadVR/LAV over DirectSound) does NOT encounter the dropouts on those same 3 machines. (But, ZP doesn’t have the same magical powers to use BD menus).
My most basic machine is an i3 with integrated Intel Iris graphics running W10, audio+video over HDMI 23.976hz through a Denon AVR.
-
I’ve now tried three different machines, with different hardware, and get the same result: bitstreaming over DirectSound delivers a dropout (accompanied by a visual hiccup not sure if it’s repeated or dropped frames) at least a few times during a 2 hour movie.
Does not matter if I launch the movie in “menu mode” or “title mode”.
Zoom Player with the same configuration (MadVR/LAV over DirectSound) does NOT encounter the dropouts on those same 3 machines. (But, ZP doesn’t have the same magical powers to use BD menus).
My most basic machine is an i3 with integrated Intel Iris graphics running W10, audio+video over HDMI 23.976hz through a Denon AVR.
Please could you list the hardware/OS combos that you've tried?
Also can you confirm if your issue is only with Direct Sound and if using WASAPI resolves it?
As reported earlier, I get drop outs with Direct Sound even with the 1080ti, so your issue might be different from the 3xxx/4xxx issue.
-
Please stay focused on the issue, without the editorializing.
-
I do not believe that bitsteaming TrueHD and bitstreaming issues have all been solved by changing hardware. The issues I have experienced seem to transcend Nvidia driver issues.
When you are using bitstreaming, JRiver just gives the file to the audio device. JRiver isn't playing the file.
A dropout in that case could just be a bandwidth problem. The files can be very large and may exceed the capacity of the hardware.
Please start a separate thread.
-
Does someone have a MC Log of a dropout happening with the latest version using WASAPI?
-
Does someone have a MC Log of a dropout happening with the latest version using WASAPI?
Hendrik, dropouts are not encountered using WASAPI on my 3 machines. Only DirectSound. If a log would be useful please let me know how to capture it. THANK YOU for continuing to look into this.
JimH, there was a bug in MC30 (and previous) Hendrik confirmed just fixed in MC31, allowing bitstreaming over DirectSound. This is the functionality my setup requires. Although it now works, there are audio dropouts every ~10 sometimes ~20 minutes. ZoomPlayer with the same config (MadVR/LAV/DirectSound) does NOT encounter the dropouts - therefore I deduce there is something unique happening with MC31 + DirectSound.
Thank you.
-
Does someone have a MC Log of a dropout happening with the latest version using WASAPI?
If you’re investigating this I’m happy to produce a log of the drop outs I encounter with WASAPI. I’ll try with the 3090 in the E-GPU first (sadly the 3060 dGPU in my Dell XPS 17 is unable to bitstream ATMOS at all), then with the 3090 in the HTPC (where the 1080ti has no issue) if I can’t reproduce these drop outs with the 3090 in the E-GPU (a Razer CoreX).
Please could you remind us or point to a link explaining how to generate the log you’re after? Thanks!
-
For reference:
https://wiki.jriver.com/index.php/Logging
In summary:
- Turn on Logging in the Help menu
- Reproduce the issue
- Use "Report problem.." in the Help -> Logging dialog to generate a zip package with the log and attach it here or mail to hendrik at jriver
-
For reference:
https://wiki.jriver.com/index.php/Logging
In summary:
- Turn on Logging in the Help menu
- Reproduce the issue
- Use "Report problem.." in the Help -> Logging dialog to generate a zip package with the log and attach it here or mail to hendrik at jriver
Thanks Hendrik.
I've done the following on my Dell XPS 17, as that's where the 3090 is currently installed, in a Razor Core X E-GPU:
- Disconnect from internet
- Uninstall all nVidia drivers with DDU
- Clean install of the latest studio drivers (537.42) without GeForce experience for the 3060 (E-GPU off)
- Power the E-GPU on
- Install of the same drivers for the 3090
- Internet switched back on
That's the standard procedure to make sure there is no conflict between the 3060 dGPU and the 3090 E-GPU.
The chain for the 3090 is:
3090 HDMI OUT >> Denon X8500HA HDMI 2.1 in >> HDMI 2.1 Out to HDFury VRROOM >> JVC NZ8 (RS 3100) or LG 4K Monitor.
I did lots of tests and it doesn't matter whether I use the LG or the JVCs, when the drop outs happen, they happen with either.
I've also tested without the HDFury VRROOM and it makes no difference re Atmos drop outs as it's after the AVR (so not part of the Audio chain).
From that point, I've changed the following settings in the nVidia Cpanel:
- Vsync on (necessary to get rid of glitches and frame drops with the 3090)
- Power: Prefer max performance (not strictly necessary, but just to err on the side of caution)
- Prefer nVidia GPU
- Reference desktop settings
- 4K23 RGB 8bits (I didn't use 12bits due to the nVidia driver issue, it's present in this configuration even though the e-GPU is connected to the HDMI 2.1 input on the X8500HA).
I used the latest version of JRiver MC 31 for my tests (build 54) and I selected JRVR Red October in the video settings, to rule out madVR and any of the custom settings I normally use. I selected the nVidia Audio device with WASAPI and bitstreaming enabled.
I played the film (John Wick 3, as I used it for my previous tests) from MC itself, I didn't launch it from CMC as I usually do, to rule out another potential (though unlikely) factor).
I used BD Menus because that's what I usually use. I also get the Atmos drop outs with direct play, so not a factor.
I waited for at least a minute after starting the film to make sure the the initial frame drops we get with JRiver are reset, so from minute 1 I had reset the usual initial frame drops and had 0/0 dropped repeated frames. I also checked that only the 3090 was used, which was the case, both the Intel iGPU and the 3060 dGPU had zero use.
I got typical results with the 3090 (it would be similar in the HTPC):
- after about 10 minutes, I get 2 frame drops and 1 repeated frame (visible).
- about one hour in, I get one additional frame drop.
- About one hour and 15 minutes in, I got 20 additional frame drops. It caused a freeze of the picture for almost a second. That's the main Atmos drop out, the one that I would not experience with the 1080ti and exactly the same settings, GPU driver and software. Usually, with madVR, I get more dropped frames than that. The drop out happened during a silent moment, so I saw the picture freeze for almost a second, but I didn't hear the Atmos drop out the way I would have if it had been a busier moment in the soundtrack. In any case, 20 frame drops at once is not normal or even typical.
- About 2 hours in, I got one more drop.
As you can see, there are no regular frame drops. There shouldn't be any as the refresh rate is exactly 23.976, but for some reason I always get a couple, which I can live with as long as there is no big Atmos drop out in the middle of the film.
With the 1080ti, I usually get a max of 2/3 frame drops per film, and I never get an Atmos drop out or a one second freeze. The only time when I get a repeat is with Pacific Rim, chapter 2 (one of my favorite stress tests as it's 1.78) , it's always at the same frame and it's caused by the content as it's entirely repeatable.
At the end of the film, the total was an unacceptable 24/1. I took a screenshot during the end credits (which caused another drop, so ignore that last one which brought the total to 25/1), see below.
As you might remember, when I did my initial tests, I had a few Atmos drop outs in the first 30 minutes of JW3, always at the same place. These do not happen anymore. I assume thanks to the fix you made to MC recently.
When I get an Atmos drop out, it's usually only one, and most often around the one hour mark. It can be a bit earlier (as early as 30 minutes in) or a bit later (as with this test, around 1 hour and 15 minutes). It doesn't always happen exactly at the same spot, unlike the other (corrected) issue.
I've sent you the ZIP with the log files by email, as requested.
Please don't hesitate to ask if you have any questions, and thank you for investigating this.
-
In addition to the above, I forgot to say thanks for fixing the CTRL-J in order to display the stats with JRVR. Before, it was necessary to click on the screen for the shortcut to register (only with JRVR) and it doesn't seem to be the case anymore :).
-
I've done more tests with MPC-Be, using the exact same config.
Another user (Klaus1189 on Doom9) asked in another thread to test with MCP-BE and its internal filters. That's not how I use it, but as I was testing, I though "why not?".
I installed the latest version of MPC-BE (1.6.9) and the latest version of MPC-VR (0.6.9.2117, which I used, again to rule out any potential madVR setting issue).
I set all the filters to the internal filters and enabled bitstreaming in the internal audio filter (all these internal filters look furiously like old LAV filters, but anyway).
I kept John Wick 3, not that I really wanted to watch it again for the 17th time, but for consistency in the tests.
MPC-BE with internal filters produced the worst results:
- After about 12 minutes, I got a micro audio drop (no frame drop/repeat visible or reported, just a brief pop in the speakers)
- After around 16 minutes, a big Atmos audio drop causing 158 dropped frames in one fell swoop (screenshot attached). That's the usual Atmos audio drop with 1-2 seconds of frozen picture before everything starts again (sound and pic in sync).
I then switched back to my normal configuration when using MPC-BE, which is using the last version of LAV Filters (I kept MPC-VR though, again for consistency and to rule out madVR). I had installed the latest 0.77.2.3 that includes the Atmos bitstream improvements.
This produced the best results, on a par with my previous experience with MPC-BE:
- No micro audio drop at 12 minutes
- No Atmos audio drop at 16 minutes
- 1 skipped frame at 44 minutes (1/0)
- 1 skipped frame at one hour (2/0)
MPC-BE with latest LAV is therefore the only combo that passed both video and audio tests with the 3090 E-GPU (no audio drop, Atmos or otherwise, and only 2 skipped frames in more than two hours, which is entirely acceptable even if not ideal).
This is exactly what I get with the 1080ti, both with MPC-BE and JRiver MC.
So these tests seem to confirm the following regarding the Dolby Atmos dropouts:
1) They are NOT caused by madVR as they also happen with JRVR and MPC-VR
2) They are not caused by the hardware or driver per se, given that it's possible to get no Audio dropouts when using MPC-BE instead of JRiver MC.
3) The version of LAV makes a big difference. Clearly using the internal filters in MCP-BE produces poor results, similar with using early MC 31 builds (before the Atmos bitstreaming improvements later ported to LAV 0.77.2.3).
It looks to me that givent the recent improvements to MC / LAV in this area (we went from 3/4 Atmos drop out in the first 30 minutes of JW3 to no drop out until around the hour mark), there might be a bit more to fix/improve in MC/LAV.
I attach, in that order, a screenshots showing the dropped frames with MPC-BE, just after the Atmos drop out around minute 16 for the internal filters (I stopped palyback after that) and during the end credits with MPC-BE using LAV external filters.
Hendrik, please could you confirm that you have received my email with the attached logs for JRiver MC?
-
Same version of madVR?
Did you test with JRVR?
-
Same version of madVR?
Did you test with JRVR?
I didn't use madVR for any test in order to rule it out as a possible cause.
I used JRVR with JRiver (Atmos drop outs) and MPC-VR with MPC-BE (Atmos drop outs with internal filters, no Atmos drop out with External LAV filters, latest 0.77.2.3 that improve Atmos bitstream).
So the issue is not caused by madVR, and the version of LAV Filters used can make a big difference.
I get similar results with madVR (no drops with MPC-BE, Atmos drop outs when using JRiver MC). This is only with a 3090 (or the 4070 I tested briefly), as I get no Atmos drop out issue with the 1080ti ever, including with MC31.
So the hardware plays a part, but the issue is not only the hardware or the driver, given that I get Atmos drop outs with JRiver MC 31 and not with MPC-BE, using the same driver and GPU.
-
Hendrik, please could you confirm that you have received my email with the attached logs for JRiver MC?
Got the logs.
-
Got the logs.
Great, thanks for the confirmation and looking forward to your thoughts.
It's good to know that I can reproduce this with the E-GPU, as it means I can run tests without having to swap GPUs in the HTPC (until this issue is hopefully resolved in MC).
-
Got the logs.
I'll get my logs to you tonight, with my DirectSound issue. Thank you.
-
SamuriHL reported audio drop outs in JRiver (WASAPI) with Atomic Blonde in DTS:X in the Doom9 thread, so I re-watched it with JRiver MC31 and JRVR. Everything else unchanged.
For info his setup is 3090 [correction: 3080] > HD Fury VRROM > video only to HDMI 2.1 OLED (I think) and audio only to HDMI 2.0 AVR. He gets Atmos audio drops like I do.
I didn't get any audio drop outs while playing Atomic Blonde, but I got more frame drops that I would find acceptable, so it might be related:
- 1 skipped frame around min 15 (1/0)
- 6 more skipped frames in one very visible chunk around minute 30 (7/0). That one could have been an audio drop with a few more frames.
- 1 more skipped frame around 1 hour and 15 min (8/0)
- 1 skipped one repeat around 1 hour and 50 min (9/1)
Screenshot below taken during the end credits and log sent by email to Hendrik.
Hendrik, please could you confirm you've got the second log?
-
I've got a 3080 but I doubt it makes any difference. My setup is:
HTPC 3080->HD Fury VRROOM -> AVR HDMI 2.0 audio out : LG G2 HDMI 2.1 VRR video out
Disabling VRR/gSync makes no difference. I also do not get audio drops in any of my games (they all use ATMOS audio). I only use JRiver MC for HTPC playback (I mean, OBVIOUSLY :D). I do split between testing madvr and my normal viewing with JRVR. Neither make any difference when it comes to the dropouts.
I did not have logging enabled last night watching Atomic Blonde, but I did have several dropouts with that which is DTS:X. That's unusual as I almost never have DTS issues with this setup. I will enable logging and capture it for all future sessions where I have dropouts.
EDIT:
One detail that I doubt matters but should probably mention here. The VRROOM mutes audio to the LG display. The output from the VRROOM to my AVR is through HDMI out on the VRROOM. I can switch it between emulating 720p or 1080p although that has no bearing on the dropout issue.
-
If you are watching another movie, perhaps try increasing the WASAPI buffer size in the settings?
Options -> Audio -> Device Settings (should open a dialog)
Default is 100, maybe try 250.
-
I can certainly try that.
-
Setting it to 250 crashes JRiver. Setting it back to 100 plays without crashing. I have a zip file of logs from the crashing. Just let me know how/where to send it. I obviously couldn't test anything with it set that way.
-
I have another log that was created during an audio dropout from an ATMOS track (Resident Evil Extinction).
-
Setting it to 250 crashes JRiver. Setting it back to 100 plays without crashing. I have a zip file of logs from the crashing. Just let me know how/where to send it. I obviously couldn't test anything with it set that way.
Same here. I get an error and playback stops. Setting it back to the default fixes it.
-
Here is a screenshot of the error with 250ms. I get this both with the 1080ti on the HTPC and the 3090 in the EGPU. I had tried this when trying various things to debug this Atmos issue a while back, so it's not new.
-
At least you got an error. For me JRiver just disappeared into the night. LOL
-
I have another log that was created during an audio dropout from an ATMOS track (Resident Evil Extinction).
Do you also experience the Atmos drop outs around the hour mark, and is it usually just one?
It used to be more often and earlier, but the latest MC/LAV improvement reduced this to one drop out per film, usually around the one hour mark.
-
Do you also experience the Atmos drop outs around the hour mark, and is it usually just one?
It used to be more often and earlier, but the latest MC/LAV improvement reduced this to one drop out per film, usually around the one hour mark.
They're all over the place for me. In Resident Evil Extinction I got one about 10-15 minutes in, and then more after an hour or so. No pattern I can see.
-
They're all over the place for me. In Resident Evil Extinction I got one about 10-15 minutes in, and then more after an hour or so. No pattern I can see.
And this is with MC31 build 54 and JRVR Red October?
-
Yes on the build. No on the JRVR at the moment, not that it matters. I'm using madvr right now for testing. JRVR exhibits the same issue though.
-
Yes on the build. No on the JRVR at the moment, not that it matters. I'm using madvr right now for testing. JRVR exhibits the same issue though.
Yes but it would be interesting to narrow it down and see if you get the same results as I do with the closest possible configuration (OS, nVidia options, etc, see my long post/report above). I would suggest you enable V-sync and fixed monitor rate (no G-sync/VRR) to help debug and possibly reduce the number of drop outs.
I also have these droputs with both madVR and JRVR, but I think it's easier for Nev to debug and fix if we test and provide logs with JRVR. It rules out an entire part of possible issues/differences and it makes everything part of JRiver (MC, internal LAV and JRVR Red October). Hopefully, if the issue is solved with JRVR, it will be solved with madVR :)
-
Unfortunately I don't have unlimited time to test right now. Maybe this weekend I can run more tests in different conigurations.
-
Similar problem?
Nvidia Control Panel setting.
https://yabb.jriver.com/interact/index.php/topic,135621.msg950166.html#msg950166
-
I didn't post in this thread since I'm not sure it's related, and I believe Manni is tech-savvy enough to have already tried this, but of course you never know ;)
-
That's how I already have my 3080 setup. So no.
-
I didn't post in this thread since I'm not sure it's related, and I believe Manni is tech-savvy enough to have already tried this, but of course you never know ;)
Thanks, it's not related as I used "prefer max performance" for these tests (please see my long post report above where I give all the details of my settings).
However, it's not really needed for my 3090, and I don't get "adaptive" as a choice (as I do with the 1080ti). The only other option is "normal", which is is fine with the 3090 here, but I wanted to be on the safe side for these tests.
For me, the two things that made a difference with frame drops/glitches with MC is setting vertical sync to on, disabling Gsync when available (set the monitor refresh rate to fixed to disable VRR) and, if using madVR, keeping the default 8 frames rendered in advance instead of selecting 1-3 as commonly advised for recent GPUs.
With these settings, you should get 1-3 dropped frames per film when using MPC-BE or with MC if not bitstreaming.
The question is, if your 3090 goes through an AVR, do you get Atmos drop outs when bitstreaming audio to WASAPI in MC31? It can take up to one hour or more to happen.
If you don't ever get Atmos audio drop outs when bitstreaming to nVidia High Def Audio WASAPI using JRVR, please post all your hardware details and settings (CPU, GPU, OS, nVidia driver version and type - studio vs game ready, standard vs DCH - as well as nVidia CP settings especially for power, vsync and gsync), so we can see if there is a common element for those who experience these Atmos drop outs vs those that don't (if any).
-
In addition to the above, I forgot to say thanks for fixing the CTRL-J in order to display the stats with JRVR. Before, it was necessary to click on the screen for the shortcut to register (only with JRVR) and it doesn't seem to be the case anymore :).
Correction, there doesn't seem to be any change with this. I guess it only went away because I was starting playback from JRiver. So it must be a focus issue that only affects JRVR and not madVR when JRiver is used as an external player.
When I use JRiver as an external player (from CMC, full screen), if madVR is the renderer I get the stats as soon as I press ctrl-J on the keyboard (or remote).
If the renderer is JRVR, I have to click on the screen to bring JRVR fully in focus I guess before it responds to ctrl-J. I've also noticed that if I press CTRL-J a few times in a row (without clicking on the screen, so without changing the focus), the stats sometimes appear.
Again, this is only an issue with JRVR, not with madVR, so it's a MC issue rather than a CMC issue, otherwise we'd have this problem with madVR too.
Sorry for the OT, but I wanted to correct my earlier post here.
-
Unfortunately I don't have unlimited time to test right now. Maybe this weekend I can run more tests in different conigurations.
I would encourage you to try to optimise your settings, because I watched Resident Evil: Extinction and had no Atmos drop outs, which can happen for a couple of titles, as it did when I tested a few LOTR titles, it doesn't mean the issue is resolved. At least it proves that they are not specific to the content, at least here (1:1 rip from original disc to BD folders played with BD Menus).
I took a log during playback and I've emailed it to Nev. Maybe comparing mine (no Atmos audio drop outs) and yours (lots of Atmos audio drop outs) might help him to identify and resolve the issue.
I also tried to use madVR, but with the XPS 17 and the E-GPU, I got lots of dropped frames that I don't get with JRVR. So I also encourage you to do your testing with JRVR. I don't have more dropped frames with madVR in the HTPC, but for some reason it doesn't seem to like the E-GPU as much. It could also be my madVR settings, that are hungrier than JRVR (even set to max quality, which is how I set it).
For this pass, I had disabled the 3060 dGPU and I had also selected DCI-P3 as the target gamut for the tonemapping as I watched the film on the JVC.
Here are the dropped frames I got (as always, I reset the stats during the first minute, until all the initial drops with JRiver have happened, which can take 30 secs to 1 minute):
- 2 after about 2 min. (2/0)
- 1 more after about 15 min. (3/0)
- 3 more in one chunk after about one hour and 4 minutes (6/0). This would have been the Atmos audio drop if the number of dropped frames had been higher.
- 1 more at one hour and 7 minutes (7/0).
Seven dropped frames is a lot more than I would find acceptable, even if in this instance it didn't mean an Atmos drop out. I attach a screenshot showing the stats during the end credits (sorry for the low res, I got the downconvert wrong).
Again, with the 1080ti I never get more than 2-3 per film, and I never get an Atmos audio drop out. Ever.
Finally, I tried to run Latency Monitor while I was playing RE:Extinction. It seems to be unhappy with ACPI.sys and Storport.sys on the XPS 17 with the 3090 in the E-GPU (which isn't surprising as the E-GPU adds a lot of latency, which is one of the reasons why I wasn't sure I'd be able to use this config to reproduce the issue).
Also, unlike the HTPC, the XPS 17 isn't dedicated to video playback, but again it's not an issue with the 1080ti or MPC-BE, so there is a margin of improvement for JRiver MC specifically, even if the issue is linked to the 3xxx or 4xxx and if in my case, for these tests, the E-GPU adds latency. I attach a Latency Monitor screenshot too. Note that I didn't get any audio drop out this time, so latency monitor can't be entirely trusted :)
Please don't discard my test due to these poor Latency Monitor results. I have the same Atmos audio drop outs issues when the 3090 is in the HTPC (AsRock X570 Creator MB, 5950X, PCI-E 4.0 16x and 32GB RAM) so as long as I can reproduce the drop outs with the 3090, it's a valid test platform.
-
Going through all that and setting things up as you suggested made exactly zero difference. Still getting drops the same as before.
-
For reference:
https://wiki.jriver.com/index.php/Logging
In summary:
- Turn on Logging in the Help menu
- Reproduce the issue
- Use "Report problem.." in the Help -> Logging dialog to generate a zip package with the log and attach it here or mail to hendrik at jriver
Hendrik, I sent you my logs. Thank you.
-
Going through all that and setting things up as you suggested made exactly zero difference. Still getting drops the same as before.
Good you tried. With the XPS 17 and the E-GPU 3090, there is a massive difference here between madVR with my usual settings (lots of excessive dropped frames) and JRVR (no excessive dropped frames, though still more than acceptable with the 3090 in JRiver). I'm sure I could optimise my madVR settings to get less dropped frames, but I prefer to use JRVR on the laptop anyway, for when I use the 3060 dGPU on the move. Not so much with the HTPC (no excessive dropped frames with either madVR or JRVR).
I assume you're using the latest nVidia drivers and Windows 11 x64, and have tried with JRVR as discussed, as it takes out of the equation madVR settings which can impact on dropped frames with 3xxx and more recent GPUs.
Have you checked that your sound settings in the control panel were correct? You can keep stereo when bitstreaming, but make sure that in the Denon-AVRHD (or whatever shows up as the nVidia HDMI output you're WASAPIng to) you've disabled all enhancements, selected 24bits 192 kHz studio quality in advanced and checked both options below ("allow applications to take exclusive control of this device" and "give exclusive mode applications priority"). It's probably the case already, just checking that everything is covered.
I only use studio drivers (DCH) as they tend to be more stable than game ready ones, and I'm using the latest 347.42 with vsync on, fixed monitor refresh (when the option is available to disable Gsync and VRR) and prefer max performance power.
-
Yes, that's with JRVR, nVidia CP set up the way you had asked, W11 x64. Sound settings are definitely correct. I use the game drivers currently but even when I was using studio this happened so I doubt that's a difference. But vsync on, max power, gSync/VRR off (fixed monitor set), etc. Same issues.
-
Yes, that's with JRVR, nVidia CP set up the way you had asked, W11 x64. Sound settings are definitely correct. I use the game drivers currently but even when I was using studio this happened so I doubt that's a difference. But vsync on, max power, gSync/VRR off (fixed monitor set), etc. Same issues.
The game and studio drivers are the same, they just update studios less often, so they break less often :)
As long as you’re using the latest 347.42 (DCH), they should produce the same results.
Weird that we’re getting very different results with similar GPU. I assume that you’re not dropping more than a few frames per film, except when there is an ATMOS audio drop out? Otherwise there is another issue at play. Did you run latency monitor?
-
I'm not dropping frames, no. I'm very sensitive to video and audio glitches so I'm very careful as to how I configure stuff. Even with gSync enabled it doesn't drop video frames because MC is set to handle refresh rate changing. I didn't have time to check the latency tool. Not sure I'm going to have any time to test again at this point until the weekend but I did want to at least try the settings you suggested and see if it made any difference.
-
I'm not dropping frames, no. I'm very sensitive to video and audio glitches so I'm very careful as to how I configure stuff. Even with gSync enabled it doesn't drop video frames because MC is set to handle refresh rate changing. I didn't have time to check the latency tool. Not sure I'm going to have any time to test again at this point until the weekend but I did want to at least try the settings you suggested and see if it made any difference.
It would be interesting if you could test MPC-BE with latest LAV 0.77.2.3 and MPC-VR, again to rule out madVR’settings. As you seem to have more ATMOS drop outs than I do currently with MC31 build 54, your test might be more conclusive than mine (no Atmos audio drop out with MPC-BE), because I occasionally have no drop outs with MC as well (as with my RE: Extinction experiment). I never experienced any Atmos audio drop outs with MPC-BE (whether I was using madVR or MPC-VR) during my tests, but I don't use it as a primary player, as that's JRiver MC. No hurry to do this, it can wait until the week-end.
-
Any comments on the logs provided? Do they help to pinpoint a potential issue?
-
I've not had time for more testing of this issue specifically. I did watch Loki season 1 from my UHD's ripped to MKV's and the dropouts were still there but much less. I also had to factory reset my G2 last night because it was behaving VERY badly. That should not have anything to do with the audio issues as no audio makes it to my G2 but I will say that eARC was enabled back to the VRROOM. Again, unless some really bizarre interaction was happening there, that seems highly unlikely. I don't know that I'll get much time over the next few weeks for testing much else. Certainly not setting up other players any time soon. I'm going to likely use madvr for my next round of watching so we'll see if the dropouts increase or stay the same.
-
Okay, I switched to Biststeam DirectSound instead of Bitstream WASAPI, watched a couple of movies (A mlillion miles away, Atmos track, and Encanto, no Atmos track on my language) and I think I've experienced the same thing. Once per movie, the movie hangs or speeds up (not really sure TBH) for a split second with a sound glitch, and everything comes back to normal.
I've never experienced that with WASAPI.
-
Okay, I switched to Biststeam DirectSound instead of Bitstream WASAPI, watched a couple of movies (A mlillion miles away, Atmos track, and Encanto, no Atmos track on my language) and I think I've experienced the same thing. Once per movie, the movie hangs or speeds up (not really sure TBH) for a split second with a sound glitch, and everything comes back to normal.
I've never experienced that with WASAPI.
Thanks for doing this test.
Please could you post your detailed hardware and software specs/ settings, as suggested earlier? I get a lot of ATMOS dropouts with direct sound even with the 1080ti, but with WASAPI I only get them with the 3090.
Please list detailed:
- Motherboard, CPU, GPU brand and model
- Full video and audio chain (brand and model of any HDMI device from the HTPC to the display including AVR, switch, etc)
- OS version
- GPU driver (version, DCH or standard, game ready or studio)
- MC version and build and exact name of the device selected for audio playback, video mode selected (JRVR, madVR or other), any change to standard MC (custom video mode, version of LAV if installed manually, etc)
- nVidia CP settings, especially power, refresh rate, vertical sync, resolution, frame rate, bit depth, Colorspace (RGB or YCC). Any setting that you change manually after a clean install of the driver.
- Windows sound panel (device selected, number of channels, exclusive use or not, enhancements enabled or disabled)
- Anything else that you think might be relevant
Please confirm that with WASAPI you got no ATMOS dropout when playing 4K UHD Blu-ray titles ripped in 1:1 quality, not Blu-ray or lower quality rips, and which 2-3 such titles in full audio and video quality you have played without any dropouts.
Thanks[/list]
-
Okay, I switched to Biststeam DirectSound instead of Bitstream WASAPI, watched a couple of movies (A mlillion miles away, Atmos track, and Encanto, no Atmos track on my language) and I think I've experienced the same thing. Once per movie, the movie hangs or speeds up (not really sure TBH) for a split second with a sound glitch, and everything comes back to normal.
I've never experienced that with WASAPI.
This is EXACTLY what I'm experiencing (just for me its a few times per movie). Ok on WASAPI but issues precisly as you described under DirectSount. Also occurs on other audio tracks like DTS and DD.
-
I looked at the logs from WASAPI, but there is nothing interesting in them, which actually makes sense considering how audio works for us. Audio is never adjusted during playback, we never intentionally introduce gaps or anything like that under any circumstances. If audio and video diverge, a video frame is dropped to compensate, not audio.
There are occasionally timing corrections in some of the logs which might result in maybe 1-2 frame drops over the entire log (assuming 24p playback) at most, but would not cause any audio interruptions.
The only reason you would get a dropout is if either MC fails to feed the audio output fast enough for some reason, or the audio device/driver causes the hiccup. I've added additional logging to document if for some reason we don't have enough audio ready to go whenever the hardware asks for more, and I've added more buffer sizes to pick from for WASAPI, although with TrueHD its almost maxing out the bandwidth so you can't really go to very high buffer sizes as the size of the buffer is reaching capacity. (TrueHD is running at a transmission speed of 192kHz 8channel 16bit, the highest out of all bitstream codecs)
What I can't log is if for some reason Windows fails to wake MC in the right moment to feed audio, which might be a problem if your system has very high wakeup latency (eg. looking at a DPC graph), but its really hard to track down, and inherently a thing outside of MC, as the WASAPI Event-driven mode basically just asks Windows to wake us when the WASAPI device wants more audio.
There are documented DPC latency problems with NVIDIA cards outside of MC all over the internet, but if thats really the cause, I wouldn't know how to determine conclusively at all.
I'm currently working on a final LAV update so I can update it in MC eventually, which should make the timing tracking a bit more reliable then the fix in MC itself, however even then wrong timing would cause video glitches, not audio glitches.
-
I looked at the logs from WASAPI, but there is nothing interesting in them, which actually makes sense considering how audio works for us. Audio is never adjusted during playback, we never intentionally introduce gaps or anything like that under any circumstances. If audio and video diverge, a video frame is dropped to compensate, not audio.
There are occasionally timing corrections in some of the logs which might result in maybe 1-2 frame drops over the entire log (assuming 24p playback) at most, but would not cause any audio interruptions.
The only reason you would get a dropout is if either MC fails to feed the audio output fast enough for some reason, or the audio device/driver causes the hiccup. I've added additional logging to document if for some reason we don't have enough audio ready to go whenever the hardware asks for more, and I've added more buffer sizes to pick from for WASAPI, although with TrueHD its almost maxing out the bandwidth so you can't really go to very high buffer sizes as the size of the buffer is reaching capacity. (TrueHD is running at a transmission speed of 192kHz 8channel 16bit, the highest out of all bitstream codecs)
What I can't log is if for some reason Windows fails to wake MC in the right moment to feed audio, which might be a problem if your system has very high wakeup latency (eg. looking at a DPC graph), but its really hard to track down, and inherently a thing outside of MC, as the WASAPI Event-driven mode basically just asks Windows to wake us when the WASAPI device wants more audio.
There are documented DPC latency problems with NVIDIA cards outside of MC all over the internet, but if thats really the cause, I wouldn't know how to determine conclusively at all.
I'm currently working on a final LAV update so I can update it in MC eventually, which should make the timing tracking a bit more reliable then the fix in MC itself, however even then wrong timing would cause video glitches, not audio glitches.
Thanks a lot for this update. I'll redo some tests when the next version of LAV is updated in MC (I assume it will be in the changelog) and I'll post new logs if I still experience the issue.
In the meantime, I'll also try to see if a "keep awake" utility is available, but the one I've seen apparently only helps when the audio starts, so it won't help with this issue.
I hope that those reporting no issue with WASAPI when bitstreaming Atmos will post their settings so that I can try to replicate, but I've asked a few times and haven't seen anything.
For example I don't know if DocCharky has an nVidia GPU or now, which is clearly an important factor in my case, along with nVidia cPanel settings.
-
I looked at the logs from WASAPI
Hendrik, will you also review the logs from my examples with playback via DirectSound?
-
I'm currently working on a final LAV update so I can update it in MC eventually, which should make the timing tracking a bit more reliable then the fix in MC itself, however even then wrong timing would cause video glitches, not audio glitches.
I've done more tests with the latest build 80 of MC31 (the one with the updated LAV).
You are correct, it doesn't seem to make a difference with this issue.
I tested on the HTPC this time, to rule out any latency due to the E-GPU on the Dell XPS 17.
This is a beefy 5950X with 32GB of RAM.
I got no drop out with John Wick 3, but I got one with Spider-Man Across the Spider-Verse, after about two hours.
Maybe the improved timing means that instead of happening every hour or so, it happens every two hours or so, so might only be an issue with long movies?
To be clear, when it happens the picture freezes for one second+ and the sound stops. It then resumes after 1-2 secs, with micro stutter initially. After a couple of secs, playback is normal again.
I have a JRiver log of the drop in Spider-Man Across the Spider-Verse.
I attach the info from latency monitor, that was running in the background.
Also, I experienced a similar drop with the 1080ti recently, and it wasn't with an Atmos file, which is why I brough the 3090 back into the HTPC. I'd like to see if it happens frequently or not, and if it only happens with Atmos or not. Although the first drops were definitely Atmos related (those that happened always at the same place, up to 3-4 in 30 minutes at the beginning of John Wick 3), since you fixed this with a JRiver update, I'm not 100% sure that these are Atmos specific.
I'll report back after a while, I need to use the 3090 regularly to see if I get these drops with non-Atmos files as well, in which case I'll start a new thread.
-
I'm currently working on a final LAV update so I can update it in MC eventually, which should make the timing tracking a bit more reliable then the fix in MC itself, however even then wrong timing would cause video glitches, not audio glitches.
Hendrik, I just emailed you a second log file - this time on a completely different older machine runnign Windows 7 (but the latest MC 31) where the exact same dropouts (only over DirectSound) occur. My email also lists the timestamps (about 6 occurrences over the 2.5 hour Blade Runner 2049) Roughly one dropout every 20 or so minutes.
Thank you.
-
I also took the HD Fury VROOM out of the chain, to make sure that it wasn't involved, and as expected it wasn't. Given that it's after the AVR (between the AVR and the JVC), it would have been very surprising if it could have an impact as it wasn't part of the audio chain.
There are posts after this so maybe it was addressed. The HDMI EDID signal chain includes everything from beginning to end. Even devices that are "powered off" but actually in sleep mode can affect the EDID chain. A device after the AVR could easily cause audio dropouts.
You have ruled this out but I wanted to share the info to the thread.
-
Just to confirm that all my remaining audio/video dropouts are NOT Atmos specific.
With the 3090, I experience these dropouts every 30-60 minutes or so, at least once per title, on Atmos, DTS-X and even standard (non-immersive) tracks.
To clarify, what I'm experiencing now, usually 1-2 times per film after 1-2 hours of playback with the 3090, is a freeze of the picture over 1-2 seconds, an audio drop out of the same time, then the picture stutters a bit while the audio catches up. After a few seconds (and a couple of hundred frames dropped), the picture/audio is back in sync and there is no further issue until the end of playback. Exceptionally, it could happen twice. Using madVR or JRVR doesn't make any difference, it happens with both renderers.
This is very different from the first, Atmos-related issues that I reported initially, where I would have the same short audio drop-outs, up to 4-5 in 30 minutes, always at the same spot, only in Atmos tracks (John Wick 3). These are entirely gone.
The remaining issue is the same whether the 3090 is in the HTPC (AMD 5950X 32GB RAM) or in the Razor EGPU connected to the Dell XPS 17 (i7 12700H 64GB RAM), so it means I can use the Dell as a testbed for this, despite the added latency added by the TB connection.
I did limited testing with MPC-BE (madVR) using the 3090, and there are similar drops as well, though not as long / disruptive as with JRiver. My remaining issue therefore can't be laid only at JRiver's feet. If the issues are with MPC-BE as well, it's unfair to ask JRiver to fix them, as they are most likely caused by the hardware (GPU) or the nVidia driver.
I've put the 1080ti back in the HTPC, as in my experience the drop outs are far less frequent with it. I'll report back once I've watched a few titles (the first one yesterday evening played without any drop outs), but if I still have issues even with the 1080ti and only with JRiver, I'll create a new thread as my Atmos specific issues seem to have been resolved by recent fixes in JRiver and/or LAV (thanks!).
-
Thanks for the excellent report.
As you describe it, it's as if the application is occasionally running out of data on the incoming side.
Are these files on a NAS drive or USB drive? Try local files.
Wi-fi? We've seen a micro-wave oven cause problems in the distant past.
Antivirus?
I know you've probably done it, but the Weird Problems thread in my signature is a record of problems whose causes were hard to find (and weren't JRiver's).
-
Thanks for the excellent report.
As you describe it, it's as if the application is occasionally running out of data on the incoming side.
Are these files on a NAS drive or USB drive? Try local files.
Wi-fi? We've seen a micro-wave oven cause problems in the distant past.
Antivirus?
I know you've probably done it, but the Weird Problems thread in my signature is a record of problems whose causes were hard to find (and weren't JRiver's).
I've done all these tests to rule out any possible cause outside of the GPU (3090) and driver.
First of all, I use LAN to access the content (on two different UnRAID NAS, and the issue happens with both). I tried using wifi to see if it makes a difference, it doesn't. I've also tried to copy a test title to a local SSD, this doesn't change anything.
Furthermore, if this issue was caused by anything like what you suggest, swapping the 3090 with the 1080ti wouldn't resolve the issue.
It's really a problem specific to the 3090 (and its associated driver).
I've watched three films since I put the 1080ti back into the HTPC, and no audio/video drop (apart from a few frames dropped, but I consider 2-3 frames per film to be acceptable/to be expected). I had at least one large drop of 1-3 seconds per film with the 3090.
If the audio/video drops come back with the 1080ti, I'll do more tests with MPC-BE, but I'll only create a new thread here if the drops only occur with JRiver MC.
-
I might be on to something.
I did get some dropouts again with the 1080ti, but only after I set vertical sync on in the nVidia CP, because I was dropping a few more frames than I was happy with.
It could be a coincidience, I need to do more testing, but I played another movie after that with vertical sync off and the drop outs were gone.
So this made me think, the way this could be hardware related without being hardware related could be because with the 1080ti, historically, I never used vsync on.
Then, with the 3090, you get a lot of frame drops (unreported in madVR, reported in JRVR) is you leave vsync off (or set by the 3D application). I'm talking about a fre frame drops per minute, so very obvious and unwatchable.
So when I use the 3090, the first thing I do is set vsync on, to get rid of the very frequent and very visible frame drops.
Another way to get rid of these, in madVR, is to reduce the number of frames presented in advance to 1. But this option isn't available with JRVR, hence why I went for the vsync on option, which works with both renderers, leaving a normal number of frames presented in advance - 8 - in madVR.
@Hendrick, could you think of a way to reduce the number of frame drops with a 3090 when using JRVR that doesn't rely on using vsync? Would it be possible to get a setting similar to the madVR "number of frames presented in advance" to resolve this with JRVR?
Remember, I use bitsreaming, so if you'd like to reproduce these frame drops with your 40xx you'll have to select bitstreaming, it might not happen otherwise.
In the meantime, I'm going to run some tests with madVR and vsync set to the defaul ("set by 3D application"), and I'll see if the drop outs go.
It might be a red herring and a coincidence, but it would make sense, it would also explain why the issue comes and goes with both GPUs, but why the 1080ti was more likely to work (as it is normally used with the default vsync option).
I've asked many times and never got a reply, but if anyone uses a 3xxx or 4xxx nvidia GPU with bitstreaming and never has audio drop outs or frame drops, please could you kindly post:
- Your nVidia cpanel settings (especially the "manage 3D settings" ones)
- You madVR rendering settings (number of frames in advance) if using madVR
- Which hardware acceleration, if any, you're using
- A screenshot of the debug OSD screen during playback would be useful too.
I've put the 3090 back into the HTPC to test this out. For now, I'm leaving the GPU in the same HDMI 2.0 input of the AVR, using 8bits (due to the nVidia bug with HDMI 2.1 GPUs in HDMI 2.0 inputs that gives a black screen with 10/12bits). If this seems to be working, I'll move the GPU to the HDMI 2.1 input and will test with 10/12bits.
-
My theory is dead, I had a drop out with the 3090 not using vsync-on (madVR with 1 frame presented in advance) towards the end of a 2-hour Atmos film (Pacific Rim).
I'd still like to know if anyone has been able to get JRiver to not drop frames with JRiver without using vsync on, and anyone able to use a 3xxx or 4xxx while bitstreaming with no issue is invited to post their settings, as suggested above. Thanks!
-
Actually, according to a Trinnov owner who experiences the same issue with a 4xxx GPU, it looks like this 1-2 secs drop out per film was introduced by a Windows update (Win 11) in August. That would explain a lot, and makes sense.
Anyway, I don't think it's a JRiver issue, so signing off this thread as my Atmos drop outs issues have been resolved (thanks again).
-
Manni, glad you've narrowed JRiver out of your issues.
My issue persists, not only Atmos but all audio types when bitstreaming audio over DirectSound. Two entirely different sets of hardware, one with W10 and one still running Windows 7, indentical behavior. No audio dropouts with the same configuation in Zoom Player - but a dropout roughly every 20 minutes under JRiver MC31.
@Hendrik - please take a look at the two sets of logs when you have some time to investigate.
Thanks.
-
Posting here because as I didn't think my issue was specific to JRiver, I didn't create a specific thread for it.
Just to say the the latest Windows 11 cumulative update seems to have resolved my last frame drops issue (large video + audio drop out after 1-2 hours).
It might be in combination with everything I tried until now, but until that update I was still getting this drop out, and I haven't seen any since the update.
If this is confirmed over the next few weeks, this would give credit to the theory I mentioned earlier that this large drop could have been caused by a windows update in August, and resolved in another windows update now.
I hope that I won't be back here to report that the drops are back. It was VERY nice to get flawless playback again with the 3090 for a full film.
I watched 3-4 films, so hopefully it's fixed for good.
I've made an image of my HTPC as of today. I'm stuck with the 532.03 driver, so I won't upgrade to 24H1 or any big update, but any small update to break this, so at least I'll have something to go back to if that happens.
Anyone with this issue, try installing the latest Windows 11 cumulative update.
-
The long audio/video drops are not resolved, they are just less frequent, and usually only after two hours or so, so only an issue with long films.
Anyway, still not specific to JRiver, so although I hope it could be fixed it might not be up to LAV or JRiver to do so.
-
Clearly there are more than one symptom being discussed here. My audio dropouts ARE unique to JRiver, while Bitstreaming over DirectSound only.
-
Clearly there are more than one symptom being discussed here. My audio dropouts ARE unique to JRiver, while Bitstreaming over DirectSound only.
Yes, my Atmos audio dropouts using WASAPI on my 3090 have been resolved by fixes in JRiver and LAV. I only update (briefly) on the long video/audio dropouts here because that’s where I initially reported them. I haven’t created a separate thread as the issue isn’t specific to JRiver and they are not Atmos specific either.
Still, I think it’s worth posting an update, as I understand that Hendrick is working on resolving them, though I haven’t seen a specific thread about that. I just wanted the devs to know that the issue is definitely worth working on, even if it’s less frequent here following the recent windows update.