Print

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

[DocCharky]

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

[SamuriHL]

That's how I already have my 3080 setup. So no.

[Manni]

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).

[Manni]

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.

[Manni]

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.

[SamuriHL]

Going through all that and setting things up as you suggested made exactly zero difference.  Still getting drops the same as before.

[htnut]

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.

[Manni]

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.

[SamuriHL]

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.

[Manni]

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?

[SamuriHL]

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.

[Manni]

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.

[Manni]

Any comments on the logs provided? Do they help to pinpoint a potential issue?

[SamuriHL]

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.

[DocCharky]

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.

[Manni]

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]

[htnut]

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.

[Hendrik]

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.

[Manni]

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.

[htnut]

I looked at the logs from WASAPI

Hendrik, will you also review the logs from my examples with playback via DirectSound?

[Manni]

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.

[htnut]

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.

[rec head]

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.

[Manni]

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!).

[JimH]

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).

[Manni]

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.

[Manni]

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.

[Manni]

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!

[Manni]

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).

[htnut]

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.

[Manni]

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.

[Manni]

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.

[htnut]

Clearly there are more than one symptom being discussed here.  My audio dropouts ARE unique to JRiver, while Bitstreaming over DirectSound only.

[Manni]

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.