Vlang have you had any luck in tracing down what is going on here?
No. At least not if it happens while you have sync mode set to “Audio”.
Is there anything we can provide or test?
Would be nice if anyone who experiences this issue could say how often/when the dropouts happened, and whether they were in any way reproducible (like seeking back).
A very weak idea: try setting audio-buffer=0.5 in mpv.conf to increase the audio buffer size, but I doubt it’ll help.
If using WASAPI, which I think PMP does by default, the windows audio mixer is bypassed and the audio is instead bitstreamed to the amp untouched. That is why multi channel audio will work even if windows is only showing 2 channels.
Are any of you running SLI? What version drivers? What GPU series/model? NVIDIA has many threads re: bitstreaming audio dropouts on their forums with other media players. This is an issue with their drivers, not PMP. PMP relies on WASAPI for exclusive mode. If the underlying Windows Audio Session API doesn’t function properly because of bugged drivers, PMP will not either. Be careful with using PHT/OpenPHT/Kodi as your comparative tests–these all have the ability to use Directsound or WASAPI. They may be working via DirectSound.
Negative Ach!lles and what I use is in my signature.
It doesn’t appear to matter what version of drivers are used. In fact my drivers were from early 2016 when I first started using PMP and noticed it. It was suggested that we upgrade and I’ve tried the last 6 iterations of drivers to no avail. I’ve also swapped out cards from the old GT 640 to the new GTX 1050 Ti.
The comparative tests with PHT/OpenPHT are relative in this case because only using WASAPI works and has been that way for some time now…least for those of us that bitstream to an AVR. Using Direct Sound would cause video to go frame by frame. I can’t remember if it’s only for TrueHD/Atmos and DTS-HD or all sound codecs. In any case there are numerous threads on those old forums regarding it.
I’d think that if this was due to bugged drivers, then why is only TrueHD/Atmos streams having the issue? DTS, DTS-HD, Dolby Digital, Dolby Digital +…none of those are exhibiting the problem.
You have a link to these threads on the Nvidia forums? I don’t find any.
@Warmongerx said:
I would like to try something to eliminate any possibility of Windows being the culprit of your issue. I would like to see if you could boot live to the embedded PMP and test for the Dolby TrueHD bitstreaming dropouts.
Would you be willing to try that?
For what it’s worth I experience this behavior on my NUC running Openelec-Plex. It does it randomly only with ATMOS audio and can’t be reliably reproduced. It’s been doing it since the first ATMOS rip that I re encoded from a BD disk. I just figured it was because I was running such an old build of PHT and just figured I’d have to live with it.
Being that it’s an issue on 2 different client players would lead me to believe it a PMS issue.
@TurboJailer said:
For what it’s worth I experience this behavior on my NUC running Openelec-Plex. It does it randomly only with ATMOS audio and can’t be reliably reproduced. It’s been doing it since the first ATMOS rip that I re encoded from a BD disk. I just figured it was because I was running such an old build of PHT and just figured I’d have to live with it.Being that it’s an issue on 2 different client players would lead me to believe it a PMS issue.
OpenELEC embedded PMP or LibreELEC embedded PMP? Or is it OpenELEC with PHT?
@Ach!lles said:
@Warmongerx said:
I would like to try something to eliminate any possibility of Windows being the culprit of your issue. I would like to see if you could boot live to the embedded PMP and test for the Dolby TrueHD bitstreaming dropouts.
- If you can reproduce the issue under embedded PMP, we can look deeper at PMP
- If you can’t reproduce it we would can eliminate your receiver and PMP out of the picture.
Would you be willing to try that?
I would, if I knew what embedded PMP even was. You have instructions on what I’d need to do? Boot from USB or something? I’m not running a NUC if that makes any difference.
@TurboJailer said:
For what it’s worth I experience this behavior on my NUC running Openelec-Plex. It does it randomly only with ATMOS audio and can’t be reliably reproduced. It’s been doing it since the first ATMOS rip that I re encoded from a BD disk. I just figured it was because I was running such an old build of PHT and just figured I’d have to live with it.Being that it’s an issue on 2 different client players would lead me to believe it a PMS issue.
I never experienced the issue with PHT or OpenPHT. I’m not sure how the clients differ from Windows to what you’re running though.
@Warmongerx said:
@Ach!lles said:
@Warmongerx said:
I would like to try something to eliminate any possibility of Windows being the culprit of your issue. I would like to see if you could boot live to the embedded PMP and test for the Dolby TrueHD bitstreaming dropouts.
- If you can reproduce the issue under embedded PMP, we can look deeper at PMP
- If you can’t reproduce it we would can eliminate your receiver and PMP out of the picture.
Would you be willing to try that?
I would, if I knew what embedded PMP even was.
Embedded PMP is basically an appliance install. PMP is the only GUI app that runs on it. LibreELEC, the underlying OS is a lightweight Linux distro built for HTPC applications. ELEC is an acronym for Embedded Linux Entertainment Center. Plex has packaged PMP into a special build of LibreELEC.
You have instructions on what I’d need to do? Boot from USB or something? I’m not running a NUC if that makes any difference.
An Intel NUC is not required. Do you have an extra drive to install embedded PMP to? If not you can do one of the following:
@Ach!lles said:
@TurboJailer said:
For what it’s worth I experience this behavior on my NUC running Openelec-Plex. It does it randomly only with ATMOS audio and can’t be reliably reproduced. It’s been doing it since the first ATMOS rip that I re encoded from a BD disk. I just figured it was because I was running such an old build of PHT and just figured I’d have to live with it.Being that it’s an issue on 2 different client players would lead me to believe it a PMS issue.
OpenELEC embedded PMP or LibreELEC embedded PMP? Or is it OpenELEC with PHT?
Openelec with PHT. It’s the build that ziggimon used to maintain.
@TurboJailer said:
@Ach!lles said:
@TurboJailer said:
For what it’s worth I experience this behavior on my NUC running Openelec-Plex. It does it randomly only with ATMOS audio and can’t be reliably reproduced. It’s been doing it since the first ATMOS rip that I re encoded from a BD disk. I just figured it was because I was running such an old build of PHT and just figured I’d have to live with it.Being that it’s an issue on 2 different client players would lead me to believe it a PMS issue.
OpenELEC embedded PMP or LibreELEC embedded PMP? Or is it OpenELEC with PHT?Openelec with PHT. It’s the build that ziggimon used to maintain.
Thanks for the response. LibreELEC embedded PMP is slightly different than OpenELEC/PHT at the base OS level. Waiting to hear back from @Warmongerx
I played back my first film tonight with a TrueHD / Atmos soundtrack, and experienced the dropouts. They were the same under all three of the sync settings, although I have got bitstream on, as audio sounds significantly better on my set up that way then sending to the amp as multi PCM.
I experienced three drop outs in the first half of the film (about an hour), then watched the second half in the Plex for Kodi plug in, with no drop outs.
@lisagood said:
I played back my first film tonight with a TrueHD / Atmos soundtrack, and experienced the dropouts. They were the same under all three of the sync settings, although I have got bitstream on, as audio sounds significantly better on my set up that way then sending to the amp as multi PCM.I experienced three drop outs in the first half of the film (about an hour), then watched the second half in the Plex for Kodi plug in, with no drop outs.
What is your normal platform? Windows?
@Ach!lles said:
@lisagood said:
I played back my first film tonight with a TrueHD / Atmos soundtrack, and experienced the dropouts. They were the same under all three of the sync settings, although I have got bitstream on, as audio sounds significantly better on my set up that way then sending to the amp as multi PCM.I experienced three drop outs in the first half of the film (about an hour), then watched the second half in the Plex for Kodi plug in, with no drop outs.
What is your normal platform? Windows?
Yes, sorry, should have said. Its a custom built HTPC, with a GTX 1050, Intel i5, Windows 10, connected via HDMI to AVR.
@lisagood said:
@Ach!lles said:
@lisagood said:
I played back my first film tonight with a TrueHD / Atmos soundtrack, and experienced the dropouts. They were the same under all three of the sync settings, although I have got bitstream on, as audio sounds significantly better on my set up that way then sending to the amp as multi PCM.I experienced three drop outs in the first half of the film (about an hour), then watched the second half in the Plex for Kodi plug in, with no drop outs.
What is your normal platform? Windows?Yes, sorry, should have said. Its a custom built HTPC, with a GTX 1050, Intel i5, Windows 10, connected via HDMI to AVR.
To clarify:
Windows 10 PMP/HD passthrough = HD Audio dropouts
Windows 10 Plex for Kodi/HD passthrough = No HD Audio dropouts
@Ach!lles said:
@lisagood said:
@Ach!lles said:
@lisagood said:
I played back my first film tonight with a TrueHD / Atmos soundtrack, and experienced the dropouts. They were the same under all three of the sync settings, although I have got bitstream on, as audio sounds significantly better on my set up that way then sending to the amp as multi PCM.I experienced three drop outs in the first half of the film (about an hour), then watched the second half in the Plex for Kodi plug in, with no drop outs.
What is your normal platform? Windows?Yes, sorry, should have said. Its a custom built HTPC, with a GTX 1050, Intel i5, Windows 10, connected via HDMI to AVR.
To clarify:
Windows 10 PMP/HD passthrough = HD Audio dropouts
Windows 10 Plex for Kodi/HD passthrough = No HD Audio dropouts
Yes, that’s correct, but only on one film with a Dolby True HD / Atmos soundtrack. So far just Dolby True HD and DTS HD MA has been fine.
@lisagood said:
Yes, that’s correct, but only on one film with a Dolby True HD / Atmos soundtrack. So far just Dolby True HD and DTS HD MA has been fine.
Wait, so TrueHD without the Atmos track is fine for you? I’ll test that over the next couple days. I’m pretty sure that all TrueHD films/TV shows have exhibited the problem regardless of it having the Atmos stream, but I’ll confirm that in the next few days on my configuration, which is the same as yours.
Ach!lles - I’ll test the Plex Embedded this week sometime, though I still don’t understand how it’s going to rule anything out. They’re two totally different platforms. The mere fact that PHT, OpenPHT and Plex for Kodi Plugin are all fine, but PMP is not should tell you that it’s not a driver problem. Unless PMP is addressing the WASAPI and bitstreaming differently than those others are.
Watching Hacksaw Ridge, which is a 2h19m film, it did it 5 times.
It may be that I haven’t watched many (any) pure TrueHD films actually. I have some short demo videos I use to check that bitstreaming is working correctly. And I have watched several films with DTS HD MA, which have not had any pops or audio dropouts. I may not have watched a full length film with a True HD (no Atmos) soundtrack. I’ll endeavour to do so and report back.
Plex embedded is not an option for me on this machine as I need Windows to run some supplementary software.
@Warmongerx said:
Unless PMP is addressing the WASAPI and bitstreaming differently than those others are.
That is exactly what I am thinking. I want to narrow out Windows Audio Session API. I have a feeling it is the Windows 10 implementation. Unlike embedded, Windows has the full Protected Audio Video Path. I want to eliminate that. The code that prepares the TrueHD/Atmos bitreams for PMP is the same across platforms. The difference is the API on each respective OS.
@Ach!lles said:
@Warmongerx said:
Unless PMP is addressing the WASAPI and bitstreaming differently than those others are.
That is exactly what I am thinking. I want to narrow out Windows Audio Session API. I have a feeling it is the Windows 10 implementation. Unlike embedded, Windows has the full Protected Audio Video Path. I want to eliminate that. The code that prepares the TrueHD/Atmos bitreams for PMP is the same across platforms. The difference is the API on each respective OS.
If that was the case though, wouldn’t it be the same for any Windows application that uses WASAPI? I have Kodi set to do the same (WASAPI / Bitstreaming) but didn’t have the issue there.
