I can comment on that!
Well, it turns out that NTP really doesn't have anything to do with it. I only figured this out about 6 months after my presentation at BA last year after some back and forth posting with DIYaudio member forta... At the time I made the presentation I felt that NTP running on all the systems did help to keep the timing together. Since then I have continued to modify and improve my streaming audio setup and currently things work quite well as long as the connection between the hardware that is streaming the audio and the hardware that is receiving it in the loudspeaker is relatively good quality. Nothing super fancy, but don't try to do it with a weak WiFi signal or there will be many more problems leading to dropouts and resync issues.
So, if I am not using NTP what am I using?
There is a protocol that is designed for "real time" streaming, in fact it's called the "real time protocol", or RTP. It includes some time base info that the receiving client(s) use to determine the playback speed. NTP is a wrapper around other data. Unfortunately it can't hold just any type of data, so for instance FLAC can't be streamed using RTP. But native PCM can and it doesn't get better than that. I stream 16-bit PCM at 48kHz in my system for instance. With a fast WiFi or wired connection you can do higher bitrates and deeper bit depths. For me that is not important.
How do I get the audio stream to each speaker and get them to play it back in synchrony?
This has also changed since I gave my talk. I now send a separate "unicast" RTP stream to each loudspeaker from my audio server. I have some shell scripts that do this for me. It's not super straightforward to explain here and there are several things going on. But the main actor is VLC, which is streaming multiple unicast RTP streams, one to each speaker. RTP is not "self starting" meaning that the client needs to know about the payload in order to receive the stream. The info used to describe the stream is provided in a few lines of text in an SDP file (session description protocol) by VLC. This can be provided to the clients in a couple of different ways, and previous I was using RTSP for this because it was easy and it mostly worked. But using RTSP does occasionally cause more problems that it solves, so recently I developed a new solution. The instance of VLC running on the audio server can also write the SDP to a file. I write a separate SDP file for each unicast stream to a local directory. I use NFS (network file system) to export this directory to all my client computers. On each client I mount this directory, and point VLC to "open" the SDP file. The client VLC finds all the info it needs about the stream in the SDP, and starts playing.
One small but very important detail about the RTP stream and its SDP file is that there is a long number that is stream ID. Each time you stop and restart the RTP stream, a new ID is generated. For this reason, the clients must get real-time access to the SDP info. If you did not get fresh SDP info, the stream could by played at most once by the clients and then the ID would change and the client would return "stream not found".
Also, I should note that all the machines in my system have a fixed IP address assigned to them by the router when they power up.
I've been meaning to put together a tutorial on streaming with some examples, but I have my hands in too many pies at this time so I haven't yet done that. Anyone who is really intent on banging their head against this challenge is welcome to contact me and I will try to help you get up and running.
Is the wireless system playback just like a wired connection?
The realities of WiFi can include brown outs (slowing of throughput) and dropouts (brief loss of connection), at least in the 2.4GHz band where I live. When I scan the network I see my neighbor's Wifi systems, their wireless printers, etc. all wanting one of the available channels. YMMV depending on the band you use and how crowded it is. When my streaming audio system starts playing and for the first few seconds (e.g. about 10 seconds) RTP is detecting and honing in on the correct playback rate from the incoming data stream. If there is a WiFi dropout and the stream is lost, my system will immediately attempt to reload it. What happens is that one channel mutes for a second before audio plays from the newly re-acquired stream - for the first few seconds one might perceive a subtle effect of the RTP syncing on certain types of instruments (e.g. piano or violin) if you listen closely. Increasing the amount of buffering can sometimes reduce the occurrence of dropouts to never, depending on how consistent the stream is being received and this might not be a problem for you. With a strong wireless connection that stays up and at full speed (or a wired connection, but what's the fun in that?) this should not be a problem. Other than that, yes it is like a wired connection that is playing non-compressed audio: in short, great!