[un1versal]

Ripped from another thread...

Ok. Saw you are saying that i should have both options enabled?

No. Sync Playback syncs perfectly the fps to the videoclock. Simplified, whenever we change the front with the backbuffer one fps is displayed. This happens fps count a second. Fully in vsync -> perfect video. Problem here is: If video and audio don't match exactly.

Use case a) The VSync Clock runs at 23.99 fps and not at 23.976 fps -> no problem for video as it is just displayed "a bit" faster -> you won't notice. Cause in perfect vsync 23.99 fps are displayed per second - perfectly matching your screen, just like a clock - always doing: tick, tick, tick e.g. frame, frame, frame - the clock just runs faster as a 23.976 clock would run - no one cares. Problem comes into play, when you have audio. Cause audio and video would go ahead of each other. Therefore one needs to do something when this is happening.

With passthrough audio: we only have two choices drop or dupe and that you can hear very loud if you have bad luck, it makes a famous psssst noise to correct this offset.
Without passthrough audio: We resample a bit and video stays perfectly in sync and you won't even notice anything

=> Reason why you should disable it when you passthrough.

In a perfect world where videos are really exactly 23.976 fps and your refreshrate is really 23.976 hz -> Sync Playback does not harm (even if you passthrough), but it won't be able to help you - as everything is perfect already. And: world is not perfect.

Use case b) You play 59.94 fps content at 60 hz -> vclock "speeds it up" automatically, cause swapBuffers every 1000 / 60.0 ms vs. 1000 / 59.94 ms -> audio needs to be speed up too.
With passthrough: drop samples (ugly, bad experience)
Without passthrough: resample with a factor > 1 - audio will get a little bit higher in tone -> but you won't realize.

Adjust Refreshrate to match video is something else - it tries to find a refreshrate, so that Refreshrate % (modulo) fps == some even non fractional value. 25 fps at 50 hz is fine, 23.976 fps at 23.976 hz is fine. 23.976 at 24.0 hz -> not fine. But with RefClock -> no issue video wise.

So to summarize:
- Use Adjust Refreshrate to match video: good precondition to have the Sync Playback do a nice job afterwards
- Use Adjust Refreshrate to match video: also if you are a passthrough audio user - cause 23.976 fps content + passthrough audio played at 60 hz - won't work without either visual stutter or audio drops.
- Passthrough audio sucks for "perfect playback" as video clock might not match fps exactly, we need to drop / dupe or resync after 200 ms off
- Enable Sync Playback to Display _if_ you don't use passthrough audio as it cares for perfect video while maintaining your audio in sync without you noticing.

Edit: Not covered in here: What happens if you play 24.0 fps content at 60 hz? How would you play 23.976 fps at 60 hz? -> Some wikipedia for the dear user able to read: https://en.wikipedia.org/wiki/Three-two_pull_down

Personally: I don't use passthrough audio at all - I have a 5.1 capable LPCM receiver which I feed directly. Since we have dcadec support - I even can decode DTS-HDMA and have perfect audio also in combination with perfect video.

This is great explanation for sure.

I have a suggestion, since the new videoplayer in v17 master cannot do passthough audio with sync playback to display enabled, how about if you enable passthough then sync playback to display is disabled and user notified and the opposite if you have passthough enabled and enable sync playback to display then same thing would happen.

That is if this is the new way going forward that is and it wont change, because I was wondering why only pcm was coming out the speaker, and only a few minutes ago anaconda mentioned this...

Would that be possible and does it make sense to do so? In an Ideal world users woul read the help text, but as you noted its not an ideal world

[FernetMenta]

I have a suggestion, since the new videoplayer in v17 master cannot do passthough audio with sync playback to display enabled

Phrasing it this way is wrong. This has never worked because you can't change the speed of passthrough audio. Only because those 2 setting were allowed to be enabled at the same time does not mean that it worked. I just removed that old crap.

Consider audio with it settings as capabilities of the system that can be used by VideoPlayer but also by other players like PAPlayer. Disabling passthrough setting entirely when "sync playback" is enabled is wrong because other components may still want to use it.
Doing it the other way round is wrong too.

Be aware that passthrough audio is only an option that has its limitations. Real-time streams like PVR is another example. In order to cope with those streams player needs to vary play speed which is currently not possible with passthrough audio, hence it gets disabled when playing real-time streams.

Note that passthrough audio has ZERO advantage over pcm. Now that we support DTS-HD MA decoding there are almost no use cases left where passthrough really makes sense.

because I was wondering why only pcm was coming out the speaker,

Reading this I am wondering if you know at all what passthrough audio means compared to pcm. You certainly don't see a pcm signal coming out of any speaker. PCM is digital and as such there is no loss of information when transmitted from a HTPC to a DAC. In terms of quality it does not matter if decoding from e.g. DTS to PCM happens on the HTPC or the AVR because the decoding can't be done good or bad. It just gets decoded.
Digital to analogue conversion makes a difference but this is independent to passthrough audio.

[wsnipex]

Note that passthrough audio has ZERO advantage over pcm. Now that we support DTS-HD MA decoding there are almost no use cases left where passthrough really makes sense.

Please consider SPDIF: For me passthrough is the only option to get 5.1 sound.

[un1versal]

I have a suggestion, since the new videoplayer in v17 master cannot do passthough audio with sync playback to display enabled

Phrasing it this way is wrong. This has never worked because you can't change the speed of passthrough audio. Only because those 2 setting were allowed to be enabled at the same time does not mean that it worked. I just removed that old crap.

Consider audio with it settings as capabilities of the system that can be used by VideoPlayer but also by other players like PAPlayer. Disabling passthrough setting entirely when "sync playback" is enabled is wrong because other components may still want to use it.
Doing it the other way round is wrong too.

Be aware that passthrough audio is only an option that has its limitations. Real-time streams like PVR is another example. In order to cope with those streams player needs to vary play speed which is currently not possible with passthrough audio, hence it gets disabled when playing real-time streams.

Note that passthrough audio has ZERO advantage over pcm. Now that we support DTS-HD MA decoding there are almost no use cases left where passthrough really makes sense.

because I was wondering why only pcm was coming out the speaker,

Reading this I am wondering if you know at all what passthrough audio means compared to pcm. You certainly don't see a pcm signal coming out of any speaker. PCM is digital and as such there is no loss of information when transmitted from a HTPC to a DAC. In terms of quality it does not matter if decoding from e.g. DTS to PCM happens on the HTPC or the AVR because the decoding can't be done good or bad. It just gets decoded.
Digital to analogue conversion makes a difference but this is independent to passthrough audio.

Yes I dindt explain myself well, Ill blame it on being up all night screaming in agony, I meant to say pcm was indicated at the AVR not speaker, there's no lcd screens on my speakers so my speakers cant really tell me, but the AVR can, theres no clicking in/out and there's no indication of anything but pcm...

And even if there's no audible difference, I still rather have passthrough and have the choice of using it or not, rather than not having any choice on the matter how to use my equipment.

Thanks for explanation... I mentioned it only because of the conversation had in IRC, but clearly not all usecases were examined and certainly is the same for passthough.

In any case the help text needs updating for these things if it already hasnt been.

[popcornmix]

Phrasing it this way is wrong. This has never worked because you can't change the speed of passthrough audio. Only because those 2 setting were allowed to be enabled at the same time does not mean that it worked. I just removed that old crap.

While I agree it can't work perfectly, with some receivers it did work completely usably.
I've had passthrough and sync playback to display enabled together for most of the last two years.
I've never heard an audio glitch from my receiver with normal files.

I understand that dropping or duplicating a passthrough packet may produce an audio glitch, but most receivers make a good job of hiding that.
With mine (Onkyo 609) I couldn't detect it.

There may be other use cases that make the dropping/duplication far more common (live streams or 24fps->25fps speedup) but many users don't rely on those.

[un1versal]

Indeed, I have had this combo just fine as well with no glitches, not all AVRs and HTPCs combos have this issue like you say.

[FernetMenta]

And even if there's no audible difference, I still rather have passthrough and have the choice of using it or not, rather than not having any choice on the matter how to use my equipment.

You still have the choice. Either use Kodi or not

[FernetMenta]

Indeed, I have had this combo just fine as well with no glitches, not all AVRs and HTPCs combos have this issue like you say.

Smooth video aka "sync playback to display" was designed to change audio speed up to 5%. It was never supposed to work with passthrough audio. The fact that you abused this setting does not make it a valid option. There are many systems like Intel pre-Haswell that can't do refresh rates of 23.976 and on those systems this combo would fail.

Stop whining if I remove old crap. This is the development section of the forum. Feel free to submit some code that is not crap. I am happy to discuss this.

[un1versal]

Im not whining... if it doesnt work with new code I merely make a suggestion at least to update the help string to reflect that.
If thats whining im lost and will stop immediately.

Its interesting popcornmix was the one who said that as well but only my reply was picked as a whine

You still have the choice. Either use Kodi or not

Yes, thats a lovely way to encourage users who only try to help in their own awkward manner, spending hours on end supporting otherusers and making all sorts of contributions . nicely tell them to F off if they dare to make an observation about their preferences dear oh deary

Q- What you call a cellar with 20 blondes?
A- A whine cellar

[furii]

Note that passthrough audio has ZERO advantage over pcm. Now that we support DTS-HD MA decoding there are almost no use cases left where passthrough really makes sense.

for anyone with an ATMOS/DTS:X setup that is not true. passthrough is the only way to get that metadata. obviously there is not a lot of material with the former yet, and none that i know of with the latter, but it will only be more widespread as time goes on. small advantage, for now, but certainly not zero.

[un1versal]

Atmos is not supported in Kodi, ffmpeg doesnt support it afaik.

[furii]

someone can correct me if i'm wrong but my understanding is that ATMOS is simply extra metadata in the TrueHD stream. all that should be needed is bitstreaming an ATMOS track to an ATMOS capable receiver.

edit: maybe i misinterpreted your statement. if by support you mean kodi/ffmpeg are not able to decode the ATMOS bits then that is obviously correct and the reason i stated passthrough does indeed have some advantage over kodi decoding and pcm output.

[un1versal]

Im not an expert for sure, but as I understand it even in passthrough your AVR will not get any indication or know that there's any atmos stream., theres a thread about this somewhere and its been discussed there to death iirc.

edit see http://forum.kodi.tv/showthread.php?tid=...pid1813258 and onwards but you can read the whole thread if you like.

[jjd-uk]

Im not an expert for sure, but as I understand it even in passthrough your AVR will not get any indication or know that there's any atmos stream., theres a thread about this somewhere and its been discussed there to death iirc.

edit see http://forum.kodi.tv/showthread.php?tid=...pid1813258 and onwards but you can read the whole thread if you like.

You need to re-read it, Kodi passes Atmos audio to an AVR with no issues since we treat it as just another TrueHD stream, however this does cause a cosmetic issue of not being able to flag to the Kodi UI that the file contains Atmos, so skins will only show the files as being TrueHD.

[un1versal]

yep