Topic: Dolby Atmos Dropouts (Read 15149 times)

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/10466
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?

jmone · « **Reply #1 on:** July 12, 2023, 08:57:40 pm »

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.

Hendrik · « **Reply #2 on:** July 13, 2023, 05:44:11 am »

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.

Movieman · « **Reply #3 on:** July 13, 2023, 11:04:02 am »

Quote from: jmone on July 12, 2023, 08:57:40 pm

Hi Vern,

What's your connection setup from your PC to the amp / PJ including any splitters / edid devices etc?

Direct HDMI

Quote

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.

Quote

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.

BryanC · « **Reply #4 on:** July 13, 2023, 11:22:59 am »

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.

Movieman · « **Reply #5 on:** July 13, 2023, 12:06:16 pm »

Quote from: Hendrik on July 13, 2023, 05:44:11 am

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.

Movieman · « **Reply #6 on:** July 13, 2023, 12:11:17 pm »

Dup - Sorry

Movieman · « **Reply #7 on:** July 13, 2023, 12:46:25 pm »

Quote from: BryanC on July 13, 2023, 11:22:59 am

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.

Hendrik · « **Reply #8 on:** July 13, 2023, 03:57:18 pm »

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.

Movieman · « **Reply #9 on:** July 13, 2023, 04:58:52 pm »

Quote from: Hendrik on July 13, 2023, 03:57:18 pm

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.

Movieman · « **Reply #10 on:** July 13, 2023, 05:02:30 pm »

Quote from: Hendrik on July 13, 2023, 03:57:18 pm

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?

Hendrik · « **Reply #11 on:** July 13, 2023, 05:10:31 pm »

There is no shared code between this and ffmpeg, so no.

davewave · « **Reply #12 on:** July 13, 2023, 06:16:04 pm »

To take advantage of fixes that are to be implemented, should we turn on or off any features?

murray · « **Reply #13 on:** July 15, 2023, 08:15:29 pm »

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.

jmone · « **Reply #14 on:** July 15, 2023, 08:22:12 pm »

You should be able to test a fix that Hendrik has already applied in MC31.0.34 (once it is on the main board).

murray · « **Reply #15 on:** July 15, 2023, 08:23:57 pm »

Quote from: jmone on July 15, 2023, 08:22:12 pm

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!

jmone · « **Reply #16 on:** July 17, 2023, 06:46:45 am »

The updated version is on the top of the board - https://yabb.jriver.com/interact/index.php/topic,136545.0.html

Movieman · « **Reply #17 on:** July 17, 2023, 07:53:27 am »

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.

murray · « **Reply #18 on:** July 17, 2023, 06:23:21 pm »

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

BryanC · « **Reply #19 on:** July 18, 2023, 08:56:46 am »

Quote from: Movieman on July 17, 2023, 07:53:27 am

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.

Movieman · « **Reply #20 on:** July 18, 2023, 09:28:23 am »

Quote

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.

Hendrik · « **Reply #21 on:** July 18, 2023, 09:53:15 am »

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.

FenceMan · « **Reply #22 on:** July 18, 2023, 10:09:51 am »

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.

Hendrik · « **Reply #23 on:** July 18, 2023, 10:10:56 am »

The kind of drops it fixed would have happened around the same time in a movie too, and not randomly.

JimH · « **Reply #24 on:** July 18, 2023, 10:45:41 am »

Quote from: Movieman on July 18, 2023, 09:28:23 am

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.

BryanC · « **Reply #25 on:** July 18, 2023, 12:06:12 pm »

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.

Movieman · « **Reply #26 on:** July 18, 2023, 08:07:48 pm »

Quote from: Hendrik on July 18, 2023, 09:53:15 am

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.

JimH · « **Reply #27 on:** July 18, 2023, 10:09:35 pm »

Make sure WindowDefender is configured and no other antivirus is in use.

Hendrik · « **Reply #28 on:** July 19, 2023, 02:25:19 am »

Movieman · « **Reply #29 on:** July 19, 2023, 10:24:07 am »

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

Hendrik · « **Reply #30 on:** July 19, 2023, 11:11:44 am »

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.

Movieman · « **Reply #31 on:** July 19, 2023, 11:27:52 am »

Using WASAPI, other options won't connect.

Hendrik · « **Reply #32 on:** July 19, 2023, 11:31:13 am »

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:

Code: [Select]

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.

Movieman · « **Reply #33 on:** July 19, 2023, 11:40:03 am »

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.

Hendrik · « **Reply #34 on:** July 19, 2023, 11:43:25 am »

Can you take a screenshot of the Audio Path while playing?

Movieman · « **Reply #35 on:** July 19, 2023, 11:46:25 am »

Which log are you looking at?

Hendrik · « **Reply #36 on:** July 19, 2023, 11:56:00 am »

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)

Movieman · « **Reply #37 on:** July 19, 2023, 12:02:47 pm »

Yep, confirm that. Re-running 36 with WASAPI selected. Interesting, if that's it because my receiver has always confirmed Dolby Atmos - TrueHD.

Movieman · « **Reply #38 on:** July 19, 2023, 01:03:05 pm »

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.

Movieman · « **Reply #39 on:** July 19, 2023, 01:05:44 pm »

Quote from: Hendrik on July 19, 2023, 11:56:00 am

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)

Got it. Since it's a HT, I always run full screen mode.

jmone · « **Reply #40 on:** July 19, 2023, 04:34:44 pm »

Glad you got to the bottom of it! and long live WASAPI (best feature added in Vista IMO)

Quote from: Movieman on July 19, 2023, 01:03:05 pm

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.

Quote

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.

Hendrik · « **Reply #41 on:** July 19, 2023, 05:14:23 pm »

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.

Movieman · « **Reply #42 on:** July 19, 2023, 08:36:16 pm »

Quote from: Hendrik on July 19, 2023, 05:14:23 pm

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.

murray · « **Reply #43 on:** July 20, 2023, 03:36:31 am »

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

jmone · « **Reply #44 on:** July 20, 2023, 06:43:57 am »

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

Movieman · « **Reply #45 on:** July 20, 2023, 10:36:23 am »

Quote from: jmone on July 19, 2023, 04:34:44 pm

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

JimH · « **Reply #46 on:** July 20, 2023, 10:56:13 am »

Quote from: Movieman on July 20, 2023, 10:36:23 am

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

Movieman · « **Reply #47 on:** July 20, 2023, 04:41:00 pm »

Quote from: JimH on July 20, 2023, 10:56:13 am

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.

Hendrik · « **Reply #48 on:** July 20, 2023, 04:54:37 pm »

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 · « **Reply #49 on:** July 20, 2023, 06:08:00 pm »

Quote from: jmone on July 20, 2023, 06:43:57 am

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.

INTERACT FORUM

Author Topic: Dolby Atmos Dropouts (Read 15149 times)