[fritsch]

Jep, that's good. DVDPlayerAudio takes care https://github.com/xbmc/xbmc/blob/master...o.cpp#L596

So nice resample for non passthrough codecs (e.g. AAC, Flac, ...) and drop / dupe for the rest.

[Piers]

Then you are as said none of those. I btw only described the technical background. Use whatever you like. Xbmc supports both.

There is no alternative to drop / dupe - if you want passthrough. So - reread what I have written.

Actually sync method automatically falls back to drop/dupe in case of passthrough. So it is safe to leave it to resample.

So I was technically correct?

On a different note, If I create an updated version can I PM one of the staff so they can update the post? If I try and edit if I have to only use 6 images which doesn't really work for an image-rich guide.

[FernetMenta]

So I was technically correct?

Makes more sense to set it to "resample" because it behaves like an auto setting.

On a different note, If I create an updated version can I PM one of the staff so they can update the post? If I try and edit if I have to only use 6 images which doesn't really work for an image-rich guide.

Post here what you want to have changed.

[Piers]

I want to be able to add more and expand the points with detailed screenshots and information. If I could have 4 or 5 reserved posts under the original that would be very helpful.

[bossanova808]

@fritsch

Reading the above it occurred to me I am NOT one of the people who particularly needs to see the blue light on my receiver, so I thought I'd give non passthrough a whirl since the sync is supposed to be better and sync, particularly with 24p materials, has always been a bit of an issue with XBMC in my experience...it's just never as tight as say MPC-HC. Not trying to be controversial, just my impression. And I fund sync much more important than pcm vs. bitstream issues. Note I have also had simialr sync issues with OE on ION and NUC type machines.

Unfortunately, trying PCM, I found the sync wavered all over the place without passthrough (I have quite good sync normally with passthorugh but use a 100ms with 24p only - was hoping to get rid of this I guess).

I:
Disabled pass through
Set sync to display on with video clock (resample audio)

Played a show...just one, so it's not a huge amount of data. But just trying to make sure I did a decent test at this point...

Details:
AMD APU custom build (see signature)
Running Windows 7 64bit
Audio out was wasapi ADM HDMI
HDMI to Denon AVR 2309
HDMI from there to Panasonic V50 plasma (with adjust display refresh rate on and 24p being identified by the telly and no jitters etc)
Audio out of the Denon to Some KEF and Sonus Faber speakers.

The sync was wavering all over the place - from nicely in sync to a solid 500ms or more out, variable over the show.

Switching back to passthrough and things are all in pretty good sync again (with the 100ms delay).

Did I do something wrong? I should have tried DirectSound as well I guess.

I am sure you are going to say 'debug log' - no problems - but I want to know, I guess - best recommended settings so that I am trying the right thing.

[FernetMenta]

The reason why a/v sync is better for PCM is that we can sync on a single audio frame. The receiver can start playing the frame without the need to decode. In passthrough mode the receiver first needs to get an entire packet, 32 ms for DD, before it can start decoding. Also we don't know how long the receiver needs to decode.

500ms is a lot and I have to clue why it was wavering. Debug log please
Can you also try to connect your XBMC box directly to the telly. I think there is some info we don't read from the receiver which may cause the a/v desync for 24p. Without an AVR I have perfect a/v sync for all refresh rates.

[bossanova808]

@FernetMenta

Looking into this (prepping to do you a debug log) - I notice in my current log

Code:

20:52:24 T:2384  NOTICE: DXVA::CProcessorHD::PreInit - The Direct3d device doesn't support DXVA-HD.
20:52:24 T:2384  NOTICE: CWinRenderer::Preinit - could not init DXVA-HD processor - skipping

...I thought I was using DXVA-HD - the 'o' thingy shows dxva2. But apparently I am not - I have an AMD A6-3500 APU, latest drivers, win 7 64 bit. This should support it I thought?

I was looking at dxva-hd as I noticed some commits related to dxva-hd sync...

[FernetMenta]

There was a sync issue with DXVA-HD but since your system does not support it we have to look for something else. debug log please

DXVA-HD is the render method. In particular for Intel graphics this has dramatically improved deinterlacing quality. If not supported it falls back to DXVA render method.

[fritsch]

The closed source AMD drivers are a pain. In windows and on linux.

[bossanova808]

Just tried with 2 more files and all perfect. So maybe just a bad fluke ... Changed settings and one dodgy file (silicon valley s02e03 720p killers)...? Will keep an eye on it. AMD on windows I have found very good in practise though (nvidia for Linux though, and latest Intel's...)

This apu = equivalent to a 6530 so would have thought it would do dxva-hd. Not a big deal I guess as I basically never watch interlaced stuff...

[bossanova808]

Hmm, apparently with multi channel in my AVR doesn't do all it's magic (volume levelling, room correction etc).

Sync is good (no further issues, osrry for the false alarm) - but that's a bit of a deal breaker, makes a huge difference...

[FernetMenta]

Hmm, apparently with multi channel in my AVR doesn't do all it's magic (volume levelling, room correction etc).

Sync is good (no further issues, osrry for the false alarm) - but that's a bit of a deal breaker, makes a huge difference...

Once we have audio DSP those functions should be available in XBMC.

[bossanova808]

I am definitely seeing sync issues coming off pause with beta4, passthrough issue (will try RC1 asap).

Things are in sync nicely till I pause (or seek maybe?), then after they are quite out.

debug log: https://dl.dropboxusercontent.com/u/1088...C/xbmc.log (25mb, an evening's worth).

During both Silicon Valley (starts around 22:04:55) and the issues I guess appear around 22:07:58 after a pause. It's like when it resumed it ignored the standard 125ms delay (although it seemed out more than this).

Same sort of issues notice in The Middle afterwards.



(PS is there anyway to turn off the frickin JSON RPC log spam - that is really annoying and the log would be 1/10th the size without it...! It's just an LCD getting the playtime, as it has done for years, so ignore that..)

[FernetMenta]

I thought that json logspam was made configurable. Maybe he did catch all positions https://github.com/xbmc/xbmc/pull/4428. I left the dev a message

hmm, with your advanced settings you never get any display latency set. is this by intent? (latency need to be under video node)

[Montellese]

I am definitely seeing sync issues coming off pause with beta4, passthrough issue (will try RC1 asap).

Things are in sync nicely till I pause (or seek maybe?), then after they are quite out.

debug log: https://dl.dropboxusercontent.com/u/1088...C/xbmc.log (25mb, an evening's worth).

During both Silicon Valley (starts around 22:04:55) and the issues I guess appear around 22:07:58 after a pause. It's like when it resumed it ignored the standard 125ms delay (although it seemed out more than this).

Same sort of issues notice in The Middle afterwards.



(PS is there anyway to turn off the frickin JSON RPC log spam - that is really annoying and the log would be 1/10th the size without it...! It's just an LCD getting the playtime, as it has done for years, so ignore that..)

Concerning the log spam you should look into whatever addon or third party application you are using because it must be terribly outdated. First of all it makes requests to the HTTP API which has been gone since Frodo so all these requests will result in errors on the client. Secondly the client seems to be hammering our TCP server by constantly connecting and immediately disconnecting multiple times per second. First of all it doesn't make much sense to perform JSON-RPC requests multiple times per second (I assume it is to get the currently playing state) and secondly this is not what the TCP server is thought for. For these things we have the HTTP webserver.