[lexi81]

he is on holiday for couple of weeks. yes we do that occasionally
maybe some one else could answer as well.

Sure you guys can take a holiday You earn it! I've been using XBMC since the XBOX and there is nothing that can replace it for me!

[skurvish]

I too am having this. On a Matricom G-Box MX2 using current firmware 1.2 and Gotham 13.2 Beta 2. Connection is over HDMI and audio is set to pass-through with DTS and AC3 capable receiver set.

Audio appears to be very slightly OOS on startup. Pause the video for any length of time and it goes OOS by 1/2-1 second. Stopping the video and restarting it seems to reset the audio sync somewhat but appears to be slightly more OOS than the initial startup.

[Koying]

Kodi does not make any difference between spdif and hdmi: it just handles ac3/dts and sends it to the passthrough sink, in this case the Android one which doesn't make any difference either.
Hence, I hardly see how the difference could come from Kodi.

Was the frodo build you tested an official one?

[lexi81]

No it wasn't an original one, that's because amcodec support only became official in Gotham. I can reproduce this with a buildroot Linux image (croniccorey's build on xda), the Gotham build has audio sync issues, the Frodo build hasn't. The OpenELEC build has the same problem, so it seems a shared problem between Android and Linux. Changing settings like digital_raw output, granting superuser rights don't fix the problem.

The thing is, when amcodec was developed on the pivos platform there has been sync issues with hdmi audio with exact the same amount of delay time. I've been trying to find code where this delay could happen, but I can't code myself so reading code is difficult as well. Haven't found anything on github yet.

[it's weird to see you using Kodi ]

I made a statement earlier where I said AAC to AC3 transcode was out-of-sync as well. This isn't the case, only audio (AC3/DTS) that is passed through directly doesn't play sync. All audio that is being 'touched' by Kodi has perfect audio/video sync.

[merschdawg06]

I experienced the same thing on an OUYA.

[steeve]

Yes, same on AM S802 + Kitkat, average sound is late by 300ms to 1s.

[lexi81]

I'm running Kodi nightly dated 05-08, problem still exists. So the changes to AE/coreaudio concerning passthrough did not affect this, most of them are for osx anyway I believe.

I've been trying to read to code to find something where thingd could go wrong, but I have no coding experience and am haven't anything. The somewhat 'good' thing is, more poeple are surfacing that have the same problem. So it isn't an isolated incident. Too bad my TV (samsung ue40f6670) doesn't recognize the bitstream produced by XBMC as a valid signal, so I have no sound through HDMI, this means I can't compare HDMI to SPDIF output for better trouble shooting.

[lexi81]

Steeve, did you try Kodi nightly?

By the way, I made a bug report @ Matricom as well. Maybe Brandon can look into this.

[steeve]

Steeve, did you try Kodi nightly?

No I didn't, is there anything in the changelog that might make you think something got fixed?

Also, I tried both XBMC 13.2 Beta and SPMC.

I am not using passthrough.

[steeve]

I followed the permission post, and that indeed fixed the problem.

I did:

Code:

chmod 666 /dev/am*
chmod 666 /sys/class/video/axis
chmod 666 /sys/class/video/screen_mode
chmod 666 /sys/class/video/disable_video
chmod 666 /sys/class/tsync/pts_*
chmod 666 /sys/class/audiodsp/*

Also, do know that "pts" is responsible for audio/video sync, so that might be because of it.

[moamoa]

I ONLY see this on my Pivos XS

Don't see any sync issue on Nexus 5, Nexus 7, OpenElec RaspPi, Asus Prime, Nook, or Windows PC. All these have perfect sync.

[lexi81]

Just did the chmod, has no effect. XBMC has Su as well.

[steeve]

Just did the chmod, has no effect. XBMC has Su as well.

I seems that I really diminished the issue, but indeed, it's still there it seems.

[colintanlk]

Hi I have the same problem. Playing over HDMI has an out of sync problem too.

[lexi81]

Just to be sure it's not permissions I contacted Brandon McAnsh about this. He has fixed the permissions in the firmware, so there is no need for XBMC to set permissions.