Do multiple AirPort Expresses keep iTunes audio synchronized?

Question

I have family members planning a party for next month, and they're looking to get a single audio track/playlist streaming across the house. Their current solution is to pick up another AirPort Express (we already have a couple), attach 2.1 speakers to each one, and use a single iTunes instance to stream to all of the speakers wirelessly.

I know iTunes already supports multiple speaker outputs, but I've never tried with multiple wireless speakers (it's always been one internal and one wireless). Will the various devices keep their audio outputs synchronized with each other? They'd very much like to avoid a sound jitter or lag, even slight, from becoming noticeable when walking from room to room.

If iTunes won't do this, will a third-party app (e.g. Airfoil) suffice? It'll all be iTunes audio, so I don't think we'd need Airfoil for anything but synchronization; even so, that may be reason enough, if iTunes won't handle audio sync on its own.

Answer 1

According to Wikipedia:

The AirTunes part of the AirPlay protocol stack uses UDP for streaming audio and is based on the RTSP network control protocol.[12] The streams are encrypted with AES, requiring the receiver to have access to the appropriate private key to decrypt the streams.[13] The AirPort Express' streaming media capabilities use Apple's Remote Audio Output Protocol (RAOP), a proprietary variant of RTSP/RTP. Using WDS-bridging,[14] the AirPort Express can allow AirPlay functionality (as well as Internet access, file and print sharing, etc.) across a larger distance in a mixed environment of wired and up to 10 wireless clients.

See the page here.

Notice the part where it says that UDP is used for streaming audio. UDP does no error correction. When using TCP (most of the time), when I send a packet from A to B, I send it, I get confirmation, then I send the next packet. When I get confirmation, part of that confirmation is an error check code. If it doesn't match with the error check code that I generated when I first sent the packet, I know the data has been malformed in some way before reaching B, and therefore I send it again.

If I have to send that packet a bunch of times before it is successfully read on the other side, that would "sound like" something unexpected. Lag is a bit different -- lag happens when there's a delay of some sort, or the line is saturated and it actually takes (some arbitrary amount of) time for the signal to get there. That could happen under either model.

The difference is, with UDP, if packets get lost or corrupt, it doesn't matter. iTunes will send whatever data is required to represent the song now. And now, and now. If you miss it or it gets malformed, oh well. It will keep sending only what is pertinent now.

Long story short: you should be fine. Any glitches will probably be short and sweet. And, out of sync? Probably not discernible to any human.