[M@yeulC]

Indeed. Thank you.

I spent very little time on the code, but it seems that the method used, while more generic since clock information is included with the stream, is not the one I chose initially (yes, colek42, ntp is basically just pings used to calculate a clock compensation for synchronization). Well, since we are talking about audio, being some milliseconds late doesn't matter that much, but I wonder if this is enough to obtain a correct experience.
I might also be wrong about the implementation in eluplus' repo, I am tired as it is quite late here

[elupus]

In my experience you can't be off by that many milliseconds before you get strange interference effekts between the two audio sources. So you need to be quite exact.

As mentioned. Mention of my branch was not for shairplay per say. But the way to get the synch into the players.

[Tolriq]

All depends if sounds have to be heard from multiple source (like audio playing in multi room) or just to deport audio to 1 player.

For multi room sync needs near perfection even if nearly impossible due to rooms reverb and positions in rooms and all those things

For audio deport from some tests and public documents it seems consensus is about -125ms / +45 ms (http://atsc.org/wp-content/uploads/pdf/a...Status.pdf)

[topfs2]

All depends if sounds have to be heard from multiple source (like audio playing in multi room) or just to deport audio to 1 player.

For multi room sync needs near perfection even if nearly impossible due to rooms reverb and positions in rooms and all those things

For audio deport from some tests and public documents it seems consensus is about -125ms / +45 ms (http://atsc.org/wp-content/uploads/pdf/a...Status.pdf)

You quite easily hear when something is off by 10ms, atleast thats enough for me when playing guitar and runs it through a dsp.
EDIT: And by enough I mean that its bareable then, its still to high latency. But thats when your playing so might be that if you have two sources and not playing it is less harsh. However I still think those numbers seems extremely high

[RockerC]

@M@yeulC, I believe you should be fine as long as it is off by less than 10ms, as that should be good enough for acceptable lip-sync audio to video synchronization in films.

You quite easily hear when something is off by 10ms

Yeah, I also find it very noticeable when audio to video synchronization for lip-sync is of by more than 10ms when watching movies.

This annoying effect is also refereed to as transmission synchronization or lip flap / lip sync error, read:

http://en.wikipedia.org/wiki/Audio_to_vi...ronization

The EBU Recommendation R37 “The relative timing of the sound and vision components of a television signal” states that end-to-end audio/video sync should be within +40ms and -60ms (audio before / after video, respectively) and that each stage should be within +5ms and -15ms.

For television applications, audio should lead video by no more than 15 milliseconds and audio should lag video by no more than 45 milliseconds.[3] For film, acceptable lip sync is considered to be no more than 22 milliseconds in either direction

https://tech.ebu.ch/docs/r/r037.pdf
http://web.archive.org/web/2008100217284...chrony.PDF
http://www.webcitation.org/60UbU5Ziv

[M@yeulC]

Well, of course, this will require some adjustments. And acceptable delay is a very subjective thing (I guess people accustomed to dubbing/playback won't be as exigent as others).

If there are multiple sources, interferences are unavoidable, unless there is only one listener and we know its exact position, so it shouldn't be a problem in practice, since we're already quite used to it (after all, we're used to a slight echo from walls, etc. in every day's life).
In any case, I'll conduct some testing in a preliminary phase to verify if it is possible to achieve a good synchronization with the current JSON-RPC interface, without modifying it.

[Rantanplan-1]

Not shure if this helps, but:

VLC seems to sync Video and audio quite well on different installations (as far as tested)

as VLC is opensource to, (and Multiplatform as well)
wouldnt it be possible to borrow some codesnipets from there, or just see how they did it?

set up in VLC is a bit a mess, maby this could be done easyer if this should finde its way to XBMC/Kodi.
(If Kodi would be abel to list other Kodi devices/installations to pick and (sync-) stream to, would be cool.)

Pointers: Netsync
and maby Syncplay to (didnt test this)

wasnt shure if i should post this in here, or in the relatet "feature request"-Tread, tought it may makes more sense here.

[RockerC]

FYI, Android M (Marshmallow?) preview images & SDK adds API supported for native A2DP Bluetooth streaming on Android TV

http://www.androidpolice.com/2015/05/28/...streaming/

http://developer.android.com/preview/api-overview.html

Previously all manufacturers had their own implementation for this on Android, like for example the new NVIDIA SHIELD Console that was just released does already support broadcasting audio over Bluetooth (with the extra remote), presumably also over A2DP (but not using the upcoming API in Android M)

http://www.androidpolice.com/2015/05/28/...-just-yet/

[shayolden]

In dry air at 20 °C, the speed of sound is 343.59 metres per second.

10ms is the equivalent of sitting 3.4 metres from a perfectly tuned TV. Remember that the listener will have headphones in their ears. I think 10ms barely perceptible and there's a little more room to move than that.

[AchimTuran]

I found a nice link: http://kb.smartvox.co.uk/voip-sip/rtp-ji...lity-voip/

[liebezeit]

Any news on this?