[jadedcyborg]

Hello,

So I upgraded to Krypton from Jarvis and immediately discovered that passthrough to my receiver wasn't working anymore. I understand that this is due to a change in how the "sync playback to display" setting works, and that re-sampling now always is required when that setting is enabled, thus no passthrough. However, in Jarvis one could chose between 3 A/V sync methods: Video clock (re-sampling), Audio Clock and Video Clock (drop/dupe audio). The latter two would still work with passthrough.

For those of us who prefer our AVRs to do the decoding, and have sync enabled, the change in Krypton is rather disappointing. Changing the defaults is understandable but why remove a perfectly fine feature? I presume there is some good explanation so I would like someone to explain why those two methods were removed.

[FernetMenta]

drop/dupe was far away from working good. have you ever tried to play some 23.976 material on a 24hz screen. or even worse play 23.976 on a 50 hz. drop / dupe can't compensate the difference of speed sync to display does apply. if you want passthrouh audio, disable sync playback to display. those two settings conflict each other.

[jadedcyborg]

I know those settings conflict each other now, but they weren't before. That's my point.

Drop/dupe wouldn't be good solution in those cases, sure, but if you have a sync drift of about 1 frame per 10 minutes or so it's perfectly fine. I don't see that as a good reason for removing it.

[FernetMenta]

you don't listen. those setting have even been conflicting for the reasons I gave. while you with your use cases may not have seen issues, others did. it resulted in unwatchabe playback

[jadedcyborg]

I listen perfectly fine, thank you. Maybe you don't listen.

I'm NOT saying to make it default, I'm saying in some cases it's better. WHY remove the option?

[FernetMenta]

WHY remove the option?

Because it was not working for many users, the way it was implemented was bad, and the strategy of corrupting audio was not good either. Why don't you stay with v16.

[jadedcyborg]

So it sucked, fair enough. Because Jarvis doesn't buffer HLS streams (which sucks hard).

[FernetMenta]

For clarity: this has not been removed for the sake of removing it. Audio sync moved from player to audio engine which has many advantages. Look at it as you would move form one place to another. You look at all your things and some are not worth that you take it with you, they would just taint the new design.

[jadedcyborg]

That's the rationale I was looking for, thanks.

[LoupD]

IMHO the best for users who want both passthrough and audio sync would be that kodi checks the movie and only if audio sync is required passthrough is disabled (and a small warning is printed so the user understands why passthrough is disabled). If such a feature is not possible I would have prefer passthrough enabled and audio sync disabled because in that case, if I watch a movie and need audio sync I can disable passthrough easily in the video menu while to disable audio sync I need to go in system menu.

[FernetMenta]

Funny that users still not seem to know what "sync video to display" does. This feature has nothing to do with audio sync. Ofc audio gets always synchronized regardless whether passthrough or decoding.

[fritsch]

You have to explain it a 25th time I think. Perhaps drawing a picture might help ;-)

[fritsch]

Let's try it.

Let's assume you are the caterer at a marathon run. You have a bottle of water and some cups. All the sports guys run besides you, always 10 guys within one minute, in very 100% exact time slots. You therefore need to make sure to fill 10 cups with water (over this minute) so that every guy gets one the very moment he / she runs besides you.

Now your problem is, that the sports guys run 10 in one minute, but you can only prepare 9 cups of water as your water production is fixed to a wall clock. That would mean, that the 10 th guy gets his cup of water he needed to wait for you. That would mean he will loose time and the 11 th guy will loose it ... and so on ...

You can solve the problem, if you speed up your cups of water production, e.g. you make really sure that there is always a cup of water available when the sportsman comes by.

So, now back to technical stuff:

The sports guys that are running in exact distances is your video clock. Every tick (vsync) is such a sports guy coming by. Your water production is the PT audio, which 100% runs at a wallclock speed, you cannot speed it up, you cannot slow it down. You either run out of packages or you have too much of them.

In easy words: The moment you have one clock (video) that you want to sync to, but the audio whatever is not adjustable as it is RAW, non interpretable PT, you have a problem doing that.

So: What's your solution to that issue?

Perhaps to tell you what the old v16 method did:
- It gave out a cup of water twice <- this would confuse AVRs as the timestamp in the IEC package needs to be monotonically increaseing.
- If there was a jogger missing, a cup of water was thrown away. <- this one made a heavy "psssst" noise.

So - did the message make it through?

[helta]

I believe you need an expert in mspaint to fully visualize this topic.

[fritsch]

I believe you need an expert in mspaint to fully visualize this topic.

:-) - how about you - I don't have windows + mspaint.