Solved No passtrough when sync playback to display is enabled.
#31
Just wanted to add a summation for others doing a search on this issue that ends here, to record my own conclusions, and why, after a period of indignation and high dudgeon on the IRC channel at a perceived backward move I've decided to relax and agree it's all good after all:

Firstly, it's worth pointing out, and remembering that those of us who had Sync Playback to Display on with passthru enabled, and were happy with it, have been experiencing a loss of quality all this time. It was compensating for the timing errors by dropping and/or duplicating the audio. Yes, many of us never noticed and were happy with it, but still, it was happening. We're not falling from an actually perfect situation here.

Now, I'm among those with a nice-but-older amplifier with only S/PDIF available for multichannel output. At first it seemed that this change downmixes everything into stereo PCM, which of course is unacceptable, but in fact you just need to enable the AC3 transcoding option in audio settings under passthrough audio, and then this change transcodes into AC3 5.1 at 640Kbit.

That is a lossy conversion. The question is, can you really perceive the difference? It's almost impossible to test these things definitively without double-blind conditions, as our perceptions are so mucked about by our confirmation bias, unless the quality loss really is very severe. Theoretically you may hear the difference, just as theoretically you might hear the effects of dropped/duped audio. It's certainly plausible that even on S/PDIF we're talking about exchanging one imperceptible loss of quality for another.

My guess is that you actually would be able to tell the difference, but probably only in certain testing passages in perfectly mastered material, and depending much on your listening conditions. Most of the time it'll be fine, and if you're really that discerning, or at least imagine that you are, you're probably a target market for a new AVR with HDMI inputs allowing multichannel PCM.

Which I may be in the future. Another reason to go there anyway is to be able to connect devices without S/PDIF outputs, like the new Apple TV, or a NUC-based HTPC.

So my next concern was that, I thought this change meant that even on a HDMI-only setup there would be a bitrate-reducing transcode, thus wiping out all the benefits of getting such a new AVR. I didn't want to buy such an AVR to end up with worse audio quality than I get now. But my understanding now is that this isn't the case.

I already understood the point, made earlier in this thread, that there is nothing inherently lower-quality about PCM, compared to passthrough of DTS-HD MA, TrueHD or any other lossless format (except the metadata issue with very new formats, which I'm not going to go into). Whether the decoding of the source happens in Kodi or in the AVR, it should make absolutely no difference to the resulting audio. The digital-to-analogue conversion is still done in the AVR, and that's where their quality can make a difference. (I wonder if some people's reluctance to let go of passthrough is a confusion between the digital-to-analogue conversion and the lossless, digital decode from an encoded bitstream to PCM?)

With this change, my understanding is that the audio from the source is decoded to a waveform which is then resampled to the outgoing PCM stream at the adjusted speed. This is all happening at 24-bit 96KHz, so while that resampling may be very slightly lossy, it really is all happening at a resolution way, way beyond our ability to hear it. Your cat may be able to hear it, but she won't tell, and she probably doesn't like it when you play stuff loud anyway. The lossiness to worry about is during compression to a lossy format such as AC3, and that isn't happening here (unlike with S/PDIF output).

In either case, though, starting from a lossless source probably does make a difference. In the HDMI + Multichannel-PCM scenario, this means that the lossless stream is the basis of the resampling. In the S/PDIF + AC3-transcode scenario, it's still always better to transcode from the best available source. So while, thus far, I've ripped my blu-rays without the lossless formats because I could only pass-through DTS-Core or AC3 to the amp anyway, it may actually now be worth having the lossless tracks there, for Kodi to transcode from.

But again, whether I'd really hear the difference is still questionable!
Reply
#32
That said...

A suggestion that maybe this behaviour could be conditional.

For instance, if sync prolems only affect fractional refresh rates, maybe the config setting should *allow* it, but it only actually happens for fractional refresh rates.

Or more generically, it could learn/remember which refresh rates, when selected, cause frames to be skipped or duplicated because they don't exactly match the frame rate of the media, and use this behaviour then, and normal passthrough otherwise. More generically still, if refresh rate does not *exactly* equal frame rate, enable sync playback to display with this behaviour. Otherwise don't do that and allow passthrough instead.

(So on this nVidia, with a custom xorg.conf, the refresh rate does *round* to 23.976, but to five decimal places is not exactly that. It's 23.97576 according to kodi-xrandr. With this xorg.conf the original problem is much reduced from the default (where the refresh rate is actually 23.97091) but still present. Therefore this resampling behaviour is still appropriate.)

My use case that made me think this:

Most of the time I use Kodi to watch TV. As I'm in the UK (and not in an NTSC-afflicted region), TV is all at 50Hz, and is either 576i or 1080i at 25fps, or encoded content (eg: iPlayer) also at 25fps. I used Kodi 17 Alpha for some time without ever seeing a problem, until one day I fancied watching a movie.

But now that I have Sync playback to display on, I do get distracting moments when the audio swoops around at a different rate before settling down, I think probably when there is some interruption to the transmitted audio stream, and of course when starting playback. Especially entertaining was when BBC switched from transmitting AC3-2.0 to AC3-5.1 while I was watching just before a programme transmitted in surround, and the speed swooped around like crazy for a few moments and when it settled was still way out of sync with the visuals; I had to stop and restart playback so it could start afresh.

(Quite by chance, as I was recording the programme before it, I recorded this happening, but for some reason the behaviour described above doesn't happen on playing back the recording as opposed to when watching live. The transition to surround is quite smooth. I have no explanation for this.)

Whereas with passthrough, it's the amplifier's job to adapt to the changing audio stream, and it does so immediately. And as there is generally no problem with sync that this behaviour is there to correct, it would actually be preferable if sync playback to display was OFF - when in this refresh rate; when it's not needed.
Reply
#33
Sync playback to display aka smooth video was designed to vary playback speed +/- 5% of original. That clearly excludes passthrough from the game. For whatever reason users may have abused this feature for PT audio in the past, they have to look for something else. The door won't open for PT again.

Quote:But now that I have Sync playback to display on, I do get distracting moments when the audio swoops around at a different rate before settling down,

I am aware of this and this state of course is not intended to be final. I am currently working on integrating ffmpeg's atempo filter, that allows to vary audio speed without getting chipmunk voices. This will allow for faster audio sync by using atempo filter for larger errors in playback speed and resampling for fine adjustments.
Reply
#34
(2016-07-17, 09:20)FernetMenta Wrote: Sync playback to display aka smooth video was designed to vary playback speed +/- 5% of original. That clearly excludes passthrough from the game. For whatever reason users may have abused this feature for PT audio in the past, they have to look for something else. The door won't open for PT again.

You've misread what I was getting at. I was too verbose.

I'm not asking for a special case where 'Sync playback to display' lets passthrough audio happen.

I'm saying, the whole feature 'Sync playback to display' should only be enabled where it is needed.

It's needed when the refresh rate does not exactly match that required for the media's framerate to be played without timing errors.

That is, when refresh ÷ fps is not a round number, an integer, there will be an inherent timing drift and we want 'Sync playback to display' to be enabled. The whole thing, with audio resampling as currently implemented. I'm not asking for that to change. This can be if we're trying to play a 23.976fps movie at an nvidia-default 23.97071Hz (refresh ÷ fps = 0.99977936269603), all the way to a 23.976fps movie being sped up to 25fps, to play at 50.00000Hz (refresh ÷ fps = 2.08541875208542), as we in Europe are used to seeing movies played on DVD or TV. if refresh ÷ fps is not an integer, then enable sync playback to display. That's all fine.

But when refresh ÷ fps is an integer, usually exactly 1 or 2, such as when a 25fps source is being played at 50.00000Hz (refresh ÷ fps = 2), then we don't need 'Sync playback to display' to be enabled at all, because there's no built-in drift. But hunting through the video playback settings to change it every time is a pain, when I would have thought VideoPlayer could work that out for itself.

In Java I would probably express this as:

Code:
boolean syncEnabled = Math.IEEEremainder(refresh, fps) != 0;

... during playback startup, when it's deciding what to do. It looks like <cmath> has an equivalent remainder() function.

It being enabled when it's not needed is not without side-effects:

  1. It's slightly wasteful. It's resampling the whole time, with no timing change actually occuring.
  2. It is lossy, eg when transcoding 1.5Mbit DTS on the blu-ray of a TV show, to 640Kbit AC3 for S/PDIF output. Acceptable when necessary (as my earlier post shows me deciding), less so when it's not.
  3. It reacts inappropriately to one-off transmission glitches, that only very temporarily affect the refresh rate to fps ratio.

The latter is I think what I described happening when the BBC transmission switched the main audio track from AC3-2.0 192Kbit, to AC3-5.1 320Kbit. With 'Sync playback to display' enabled, I think it registered a speed change at the switch, and briefly went faster to catch up, at the end of which it was a second or so out of sync with the video. Whereas the normal behaviour, when 'Sync playback to display' is disabled, is just to skip frames as necessary so it can carry on. In this situation, that's what we want.

So to reiterate, 'Sync playback to display' is for when there is a structural timing drift. Frame rate does not fit exactly into refresh rate. When it does fit exactly, 'Sync playback to display' should not be necessary, and it can find itself overreacting to false positives, singular momentary glitches in a transmission stream, for instance.
Reply
#35
There is always a drift in timing because your display's pixel clock is not synchronised to anything. Sooner or later a video frame needs to be duplicated or skipped if playback is not synchronised to display.

Quote:It's slightly wasteful. It's resampling the whole time, with no timing change actually occuring.

Not quite correct. Live streams demand a resampler regardless of sync playback to display is active.

Quote:With 'Sync playback to display' enabled, I think it registered a speed change at the switch, and briefly went faster to catch up, at the end of which it was a second or so out of sync with the video

Wrong. When an audio stream changes its config, AE gets reconfigured.

What you observe here has nothing to do with "Sync playback to display" but with live streams. This is why you don't observe anything on the recording.
Reply
#36
(2015-12-16, 09:04)FernetMenta Wrote: 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.

Your architectural decisions seem to be flawed, when your guesswork is promptly debunked by the existence of optical audio, the defacto standard of surround sound a few years ago and the hardware that goes with it.

(2015-12-16, 12:00)wsnipex Wrote: Please consider SPDIF: For me passthrough is the only option to get 5.1 sound.

You are essentially rendering Kodi v17+ useless for optical audio with your ivory tower development, ignoring user warnings. Crappy this, crappy that... those crappy solutions are proven and make your current solution look worse.

I wanted to test the above suggestions for transcoding, but once both 'Change refresh' and 'Sync to display' are enabled, 'Change refresh' is ignored in Alpha2 (nVidia current driver). Sticking to 60Hz instead of 23.976Hz. A nightly fixed this, but ended up stuttering with steady increase in 'missed' count.

And seeing you are discussing frame blending and smooth motion now, while those might be OK for sports or soap operas, enthusiasts despise them for cinematic content. You seem to have good intentions, but this is all over the place right now architecturewise.
Reply

Logout Mark Read Team Forum Stats Members Help
No passtrough when sync playback to display is enabled.1