(30-Oct-2016, 12:31)streamy Wrote: Maybe I'm wrong as I do not have any Sonos system, but from what I can find on internet, the Sonos wireless requirements can probably not be compared to the one of Devialet Phantoms. Sonos is a streaming system that wirelessly connects stereo speaker systems, e.g to multiroom systems, not left and right channels separate streaming. So the requirements on latency for Sonos are in ms range. Not so when you stream left and right channel to separate speakers the latency between the channels needs to be below 20us, else phase shifts between left and right channel start to produce frequency shifts and unstable soundstage. Which technology Devialet uses to to keep the Phantoms in sync is not published. But from my listening experience with by the way a rock-solid streaming experience through the built-in PLC I assume that Devialet achieves to keep the latency between the Phantoms below 20us. Here https://imgtec.com/blog/the-future-is-wi...sation-ip/ you can find information regarding a specific wireless communication that accounts for short latency and others that do not. So the challenge is not on the amount of data that needs to be transferred, but on how the wireless recipients are kept in sync. Wifi per se is not good in keeping sync and relies only on packet buffering and repeated transmission. Wired streaming (PLC, ethernet, USB, etc.) have clear advantages when it comes to sending sync signals. So I suspect that this is the reason why the Phantoms work reliable in case the PLC or ethernet works and allows sync communication outside of the TCP/IP protocol. Problems occur when people use power surge filters and Ethernet that have set port restrictions or Wifi only, except for communication to a single Phantom.
I would think that if the device platform allows for a certain amount of buffering time between the time the user tries to play a song and when it's actually played, that gives enough time for the source to be delivered to each device, and the output is synchronized by playing the signal back against a common clock. So while packets may reach each speaker at different times, they arrive before the time they're set to play. Each packet is assigned a time to be played, and each speaker plays its respective packet at that time, using its clock, which is synchronized with the others.
So the complexity must come in clock synchronization. There's variation in the time it takes for clock broadcasts to reach each device (e.g., variations of 100ms can be found when using NTP), and each device's clock itself will drift over time. If the devices exchange clock broadcasts within their own wifi network, say over the 802.11 time sync function (TSF) standard, single-hop drift times can be as low as 20us, but they quickly ramp up to the 100s us over multi-hop networks. I would think you'd want to prioritize minimum drift times between stereo pairs (which should be possible with off-the-shelf standards like TSF), as 100s of microseconds of drift probably isn't a big deal between different rooms.
Anyway, interesting question, I'm not an expert but the discussion got me thinking.
