[Drag0nFly]

A recent git-compiled version of the FernetMenta branch (14.0-ALPHA1 Git:20140531-4cbf928) is showing audio sync issues when playing transcoded FLAC streams. It appears something changed in recent days, as the one I compiled from May 16th (14.0-ALPHA1 Git:20140513-7b794b7) works fine.

The audio 'usually' gets back in line when pausing/unpausing, but sometimes one has to stop and resume the stream.

I immediately reverted back to the aforementioned XBMC build (from May 16th), using the same sync settings and it works without issues (also tried all other settings i.e - Resample+Skip/Duplicate & Audio clock), but they behaved the same. For the record I am using a 175ms sync delay by default, but changing this did not rectify the problem with the latest build.

Debug log: http://pastebin.com/kcG3WnfW
(I looked through it though, but can't find anything relevant to the audio sync issue unfortunately)

[FernetMenta]

Is this only with flac? How far does it get out of sync?

[Drag0nFly]

It has gone out of sync with about a second or second-and-half before I've either paused/resumed the stream or restarted it.

I wanted to do a more extensive test yesterday (sorry for the late reply), but got sidetracked when I installed (and subsequently had to revert) the most recent Intellinux drivers (libva*1.3.1, libdrm*2.4.54 & xf86-video-intel-2.99.911) as they broke multi-monitor support (all that compile work+.deb packaging for nothing!)

But anyway, I did test a Dolby Digital Stream, which was ok, and also a DTS stream, which also appeared ok.

I will most likely be able to do a more complete test today (i.e, watching an entire movie) to make sure. The FLAC issue obviously came as a result of me watching a whole feature (and comparing a second MKV with a FLAC track), but it was however quite noticeable early on (within 5 minutes)

[Drag0nFly]

I verified this again last night to rule out issues with audio across the board, but so far the issue (only) affects FLAC streams. I watched a whole feature with a DTS soundtrack and no audio sync issues were detected.

btw.–the video appears to be slightly more fluid than previous versions (or maybe that is just me?) I detected one dropped frame in about 30 minutes runtime.

[FernetMenta]

Thanks for those infos. Those are helpful to track this down. FLAC audio frames are quite long in duration. This gives me an idea where to look at.

[Drag0nFly]

No problem. Let me know when there are things to test and I'll check out the git source tree again and recompile.

I hope to be able to test a Dolby TrueHD stream as well, just to rule out any issue with transcoding audio in general (since it is handled, from the receiver point of view, the same way as a FLAC stream in that it is processed into Dolby Digital 640 kbit/s for S/PDIF output), whereas DTS HD MA obviously is more compatible in that it extracts the DTS Core.

[fritsch]

Wait. You talk about transcoding, right? Multichannel flac transcoded to Dolby and output as AC3?

[Drag0nFly]

Correct. FLAC streams would have to go through this process for any receiver (since none, AFAIK, support it directly), but Dolby TrueHD streams could theoretically be treated differently which is why I wanted to rule that out. I have only a few films with TrueHD on the media server so haven't been able to test this as yet.

[fritsch]

Flac is normally decoded and output via LPCM. So the transcoding path you use is something special. For TrueHD I think we also don't get the Core, but rather decode and encode (in spdif +ac3 transcoding case) - but did not look into that bit stuff for longer.

[Drag0nFly]

Yes, S/PDIF (optical/coaxial) does not as we all know support 5.1 output over LPCM (even though it has more than enough bandwidth to do so), so it has to be re-encoded into DD 640 kbps. However, the material I tested on actually only had either a mono track or a stereo track, so I suspect the standard path was indeed used. I also tried the option to recode the mono track into two-channels, but it behaved the same.

And it is right that TrueHD has to be re-encoded to be output on S/PDIF (i.e, does not contain a core stream as DTS HD MA does, which is one of the reasons it became the 'standard', since non-HD audio devices only had to support one stream instead of two.)

[Drag0nFly]

Finally had time to do some more XBMC tests. Tested several other FLAC streams, including multichannel, and they quickly (within a minute) drift out of sync. (XBMC version is 14.0-ALPHA1 Git:20140531-4cbf928, from June 1st.)

Also did a test with a TrueHD track, which came out interesting. It has even worse behaviour than the FLAC streams and start to stutter within the same timeframe as the FLAC streams take to go out of sync. This is with the sync settings set to both 'Video clock; Drop/Dupe Audio' and 'Video clock; Resample Audio'. I went back and forth between the two versions to test to make sure they behaved differently. So something appears to have happened between May 16th and June 1st.

Debug log: http://pastebin.com/LGaTV2yD

For the record, the last working version (which I just re-tested) is 14.0-ALPHA1 Git:20140513-7b794b7, from May 16th. It still has minor issues when using Drop/Dupe on TrueHD (audio hiccup every few seconds, not very noticeable but it's there. Disappears when using 'Video clock; Resample Audio'.)

[fritsch]

Same with mainline?

[Drag0nFly]

As stated before, I cannot test mainline as it does not support multi-head. I have limited time to run XBMC tests, so they are being run on my main XBMC rig.

[fritsch]

what? All the X11 changes were merged into mainline.

[Drag0nFly]

That is news to me. I've asked about this on several occasions; the last time about a month ago where it was stated that mainline still relied on SDL.
If the work from FernetMenta's branch has been merged in since then I can re-test this when I recompile a new XBMC version.