Dolby-Processing: People buy soundbars and don't know what they do - and then say: I only get 2 speakers ... 2 channels ... but, but, but it was 1000 bucks and so on. Though - they connect it to ARC only, or it only supports 2 pcm channels. That's why e.g. FireTV or Shield allow a "dolby processing" feature. That takes all the PCM input and makes Dolby AC3 or Dolby DD+ from it, which only uses 2 channels bandwidth to send it out. This gets directly active when a sink is shortly unloaded, which happens on wide seek, etc. where the sink is reconfigured.
Audio video sync: The only guy inside kodi that knows how Audio and Video fit together is the VideoPlayer. No matter what the internal logic does (counting seconds, bytes, don't know) how should it ever know what offset to apply? (Dynamic part). Fixed part could work with one difference: if they do it in Software, which I highly suspect, they might manage it via CPU-loop back and fool around with the audio buffers - e.g. faking old delay up, trying to delay output below. This again will nicely fool VideoPlayer who does a whole lot of things to "match" Time video is on screen (VBlank, fences, etc.) and also Audio: after each packet it asks the Audio-Engine: GetDelay() - so that it can guarantee a smooth playback with both Audio / Video being perfectly in sync.
Though: The android system is not made for that really :-( until the new TimeStamp API, which you are only allowed to call every second (!) and then interpolate yourself - the only choice you had was "remembering" how much "ms" you already played, asking the headPosition of the API, which only updates every 200 ms if you are happy and calculate back from that. This is especially horrible in the "RAW" API, where delay and especially pause bursts is highly guessing things. It is better with IEC API, but not good. I use a moving average inside Audiotrack to cope with that. [1] (if you have too many samples, AE will realize, if you have too few, AE will see the non existing buffer drop).
Refreshrate switching, which most other android players don't support, also does not really help.
From the technical limitations of this platform compared to Linux or Windows - I am quite happy that people only complain for "one outtage" in a movie
If you are interested in the code, check how many lines (100ts) the AudioTrack GetDelay method is:
https://github.com/xbmc/xbmc/blob/master...K.cpp#L646
And compare it to Linux:
https://github.com/xbmc/xbmc/blob/master...A.cpp#L880
I think this says it all ... Android made a long way unti what we have today, but not yet a perfect A/V delay possible by design.
[1]
https://github.com/xbmc/xbmc/blob/master....cpp#L1187
