Sorry for the length of this answer - it represents several weeks of trial-and-error research. I'm afraid the details may matter so I've provided more rather than less. It's focused on audio sharing
Like others on this thread, I've been interested in having synchronized audio distributed throughout the house with spaces where the acoustic environments overlap. Since sound travels at about a foot/millisecond, this requires synchronization at approximately the 10s of millisecond level. I've found a way to make this work with VLC and have it remain in sync for hours without wandering. While I admit that I've looked at the VLC source code to try to understand which clocks are being used, I don't pretend to understand what's going on there. Furthermore, much of what I've done has been empirical. Thus, if the folks who really do understand VLC offer clarification on a better way to do this, I'm most receptive. With those caveats out of the way here's what I've done that seems to work.
Configuration
I have four areas where I'd like to share audio and a collection of computers of various vintages I'm willing to devote to provide audio. Some of these machines run Linux (Ubuntu 12.04) while others run Windows. Overall, it was easier to sync the Linux boxes than the Windows boxes, but it was possible.
On the Linux boxes, it was necessary to update the pulseaudio drivers using ppa:ubuntu-audio-dev/ppa to get the low latency version. Otherwise, the configuration was vanilla. VLC complained about latency without this upgrade. I'm hoping that when we get the 14.04 this problem will go away.
On the Windows boxes I'm running Windows 7 Pro.
The audio is served from VLC a Linux box that is independent of the playback machines. It's just downstream of the firewall where the network enters the house.
The network is a mixture of gigabit wired and wireless (802.11g).
Things that may not matter
Because I'm a time nut, all the machines are locked together in time at the sub-millisecond level using NTP. On the Linux boxes this is trivial. On the windows box, I'm using the Meinberg implementation of ntp (found at http://www.meinbergglobal.com/english/sw/ntp.htm) The box that is serving the audio is synced to the normal external time servers. However, the playback machines have their time synced exclusively to the audio server and follow it closely. The line from the ntp.config file on the playback machines that does this is
server 10.17.0.12 iburst burst minpoll 4 maxpoll 4 prefer
This ensures that time checks are done every 16 seconds - obviously I'm not concerned about network traffic.
Server
The server is set up to monitor the PulseAudio stream so that anything I play on the server will be fed to the output stream.
The output stream is an rtsp stream serving two channels at 44.1kHz. Again, there are probably things I could do to conserve bandwidth, but I'm more interested in getting the sync right than in minimizing bandwidth.
In the Preferences (Under Tools)
In the Simple settings, Audio - ensure that Time-Stretching audio is enabled
For the rest of the settings, click "All" at the bottom of Preferences page
Allow real-time priority
- Network synchronization - Check Network master clock and provide the IP of the Master server (this machine in my case)
- Audio - enable High quality audio resampling and check Enable time stretching audio
- Input/Codecs - this one seems to matter the most - scroll down to the bottom of the page
- Set Network caching to 300ms - you may need to vary this based on the speed and contention of your machines - on mine 300 is enough
- Clock reference average counter - I found that 1000 worked well - this seems to affect how quickly the synchronization follows small changes in time
- Enable Clock synchronisation
- Clock jitter - 30 ms works on my systems
- Check Network synchronisation
- I've provided file names for Record directory and Timeshift directory - I don't know if this matters
- Timeshift granularity - I've set to 1000, again, I'm not sure this matters.
Clients
Set up the clients to play the stream your server is providing.
The clients are set up to match the master with a few exceptions - here I'll list just the differences
Windows-
Preferences
- Increase the priority of the process
- Set the clock source to System time (Dangerous!) - I've tried the other settings and they tend to drift. This seems to work well as long as the NTP is doing it's job. When I turn off NTP, things begin to drift. From looking at the source code, it appears that this option uses
GetSystemTimePreciseAsFileTime ()
- on modern systems this is a sub-microsecond timer and appears to be the clock that NTP is managing. I'm sure there's a reason it's marked Dangerous so use at your own risk - it seems to be working for me.
- In Network Sync - Don't check the Network master clock (this is client after all) Do supply the IP for your master clock.
Otherwise, everything is the same as on the master.
Linux -
Preferences
- You don't have a choice on the clock - you do need to provide the IP of the master just as you do for Windows.
Caveats
Having said all of the above, all of the Linux clients I've set up seem to work well - even a very antique netbook with very little horsepower.
Windows is a different story. I've tried two boxes both with i7 processors - they are relatively new and fast. One, a Lenovo laptop, works with the recipe above. The other, a Shuttle Box, worked to a certain degree but after a few hours would start drift. I finally gave up and set it up to dual boot with Ubuntu. Once I did that, everything just worked. While I'm convinced that Windows can be made to work since I have an existence proof, Linux seems to be closer to a reliable solution. I now have three boxes with the Linux client and they all work flawlessly and stay in sync on time scales of many hours without needing to restart the VLC client.
I really haven't found a good supported solution. I think I'm going to end up purchasing a rs232 controllable multizone audio matrix, and run a bunch of wires from the points I need sound output, sound input. Sucks, but every software option was either unsupported, added lots of latency, or the syncing wasn't begin done when multiple output zones were being used at the same time. I guess I just don't understand why a solution doesn't exist over TCPIP – zimmer62 – 2009-11-23T19:38:19.097