[DDDamian]

https://github.com/xbmc/xbmc/pull/713#is...nt-4162815



Does this mean the feature has now hit eden?

Yes

[sebj]

Awesome, so happy about this!

I'm sure this will rejoice many videophiles using xbmc!

Many thanks to a11599 and all who helped bring this to eden.

I'll compile it tonight and give it a spin!

Really stoked!

[Bonzi]

Big thanks to everyone involved to get this one in .

[ashlar]

Yes

THANK YOU! Common sense ha prevailed! Really, really happy. More about the decision itself than anything.

[DDDamian]

Thank developer a11599 - he's doing some pretty awesome stuff

[negge]

+1 for merging this into Eden. Let's hope the root cause will be found before the next major version so we can get one step closer to perfection!

[sebj]

@negge

It's already been merged in EDEN.

Should show up in rc1 afaik

[meridius]

Was just wondering what exactly does this patch do ? As I delay my dts tracks by 200ms which i do automatically. Does this patch fix the sync issues with all video formats.

Cheers

[DDDamian]

It's a workaround - it let's you set global delays based on refresh rates.

[meridius]

Mmmm strange as I get perfect sync with 24p stereo and Dolby digital and mono tracks but I get bad sync problems with 24p dts tacks. So this would be no good then in fixing this type of sync issues as it would offset my none problem 24p tracks, so in fact ts would reverse my problem meaning it would put all my perfect sync tracks out of sync and my dts tracks in sync ?

Not really a fix if this is what it does. I wish the xbmc team would fix ths problem as this has been posted many times over the year and it's one of xbmc biggest problems audio sync in 24p mode with some sound audio types

Maybe a patch that lets you set sync for refresh rates and also audio types. Until a proper fix in the new audio engine is released.


Cheers

[sebj]

I know my asound.conf forced everything out at 48000 for a while and that caused issues with [email protected]

Or, maybe you're using a dmix?

Here's mine from a geforce210

pcm.!default {
type plug
slave {
pcm "hw:0,3"
}

I can relate, way to much time over the years getting this cool 24p native mode.

I'm using modelines and no sync to display mode, just vsync. Trying to keep it as bare as possible.

a11599 also has some neat patches for dts : https://github.com/a11599/xbmc/commit/b2...384558318d

the man's on a roll

[sebj]

If you've been using the previous version of the fix it's different in rc1

I'm testing a fresh build of openelec with rc1

https://github.com/xbmc/xbmc/pull/713

<advancedsettings>
<video>

<!-- Compensate display latency (video lag). Latency is given in msecs. -->
<latency>

<!-- Global default display latency -->
<delay>0</delay>

<!--
Override latency for given display (not video) refresh rates.
When XBMC is in windowed mode, override is ignored. Multiple
overrides are allowed.

Syntax of an override entry:
<refresh>
<min>, <max> refresh rate range, OR
<rate> exact refresh rate
<delay> display latency for the given refresh rate
</refresh>
-->

<!-- Example: display has 125 msec latency at 23-24 Hz -->
<refresh>
<min>23</min>
<max>24</max>
<delay>125</delay>
</refresh>

<!-- Example: display has 50 msec latency at 50 (+/-0.01) Hz -->
<refresh>
<rate>50</rate>
<delay>50</delay>
</refresh>

</latency>

</video>
</advancedsettings>

[GJones]

The patch seems to calculate a default delay. For my system, the default was very high, though I did not need one. Upon installing RC1, I had to put a section in advancedsettings.xml to hard set the delay to 0.

[bobo1on1]

Fixed: https://github.com/xbmc/xbmc/commit/1924...73aa3edb1d

[a11599]

Yeah. The only use case I haven't tested is what happens if you don't have an advancedsettings.xml (or <video> tag)...