I'm intrigued by multiple multi room audio vendors now touting solutions where not only multi room speakers are synced over wifi but also stereo pairs are as well.
From various older posts I've read the latencies and timings achieved are such that trying to achieve realistic and stable stereo results from two independently wifi connected speakers seems impossible so I wonder if the start of the art has advanced?
What latencies are folks currently getting? Even better does anyone have a measure of latency/sync differences between two seperate devices in a multicast? Has anyone ever managed to listen to such a stereo pairing?
From various older posts I've read the latencies and timings achieved are such that trying to achieve realistic and stable stereo results from two independently wifi connected speakers seems impossible so I wonder if the start of the art has advanced?
What latencies are folks currently getting? Even better does anyone have a measure of latency/sync differences between two seperate devices in a multicast? Has anyone ever managed to listen to such a stereo pairing?
I'm not sure what the current "state of the art" is and which platform (hardware or software) can exactly do what, but I can tell you of my own experiences up to last year when I had to take everything down for a move.
I was using a software approach on both the TX and RX machines. I used a local GPS syncronized (Stratum 1) time server and NTP to sync the clocks on all the machines on my network. This allowed me to get them all within about 50 microseconds of each other, and this is well below the level at which a stereo image wanders when each speaker has its own WiFi stream. So I would call it a success. I used gstreamer to manage all the audio streaming, and streamed 16-bit 48-kHz PCM (uncompressed) audio using RTP, which includes timing information. I could have just as easily done 24/96 but higher sample rates are not really as easy to do. Each RX client used identical hardware, and the playback chain was identical. I never did make measurements e.g. with a DSO or other means of the output from the clients to confirm sync, but the playback always had a central stereo image and this was enough for me.
For some perspective, when I last checked many multi-room systems can get sync to around a couple of milliseconds, some maybe can do better than this. That is just fine for one system per room, but not good enough to send a separate L and R signal to each speaker (which was my goal). Likewise, while a few tens of microseconds is fine for the stereo image, I would never try to send each band on a separate signal, e.g. woofer, midrange, and tweeter. The problem will come with higher crossover frequencies, where a few tens of microseconds is a significant percent of the period of the soundwave and will cause the relative phase to move all over the place. On the other hand, you can send a separate signal to a subwoofer crossed over at 200Hz or lower, since the timing requirements are much less severe. This means you can have a stereo pair and multiple distributed subwoofers and all can receive their own dedicated audio stream.
Also, I don't multicast because that doesn't work with WiFi. Instead I use multiple unicast streams.
As for latency, that is a whole separate issue. In my application it could not be lower than a few tens of milliseconds (e.g. 30msec). I often operated at around 100msec just to make sure the buffer on the RX end of the transmission did not run dry. Several other buffers (send, processing, DAC buffering) all meant the total end-to-end latency was often 500msec or more. Since I used my system only for distributed music playback I didn't care about the total latency all that much, but this would be totally unacceptable for audio+video use. I am sure that there are lower latency hardware based systems, but I like to code and so I DIY'd a home-brewed system.
I was using a software approach on both the TX and RX machines. I used a local GPS syncronized (Stratum 1) time server and NTP to sync the clocks on all the machines on my network. This allowed me to get them all within about 50 microseconds of each other, and this is well below the level at which a stereo image wanders when each speaker has its own WiFi stream. So I would call it a success. I used gstreamer to manage all the audio streaming, and streamed 16-bit 48-kHz PCM (uncompressed) audio using RTP, which includes timing information. I could have just as easily done 24/96 but higher sample rates are not really as easy to do. Each RX client used identical hardware, and the playback chain was identical. I never did make measurements e.g. with a DSO or other means of the output from the clients to confirm sync, but the playback always had a central stereo image and this was enough for me.
For some perspective, when I last checked many multi-room systems can get sync to around a couple of milliseconds, some maybe can do better than this. That is just fine for one system per room, but not good enough to send a separate L and R signal to each speaker (which was my goal). Likewise, while a few tens of microseconds is fine for the stereo image, I would never try to send each band on a separate signal, e.g. woofer, midrange, and tweeter. The problem will come with higher crossover frequencies, where a few tens of microseconds is a significant percent of the period of the soundwave and will cause the relative phase to move all over the place. On the other hand, you can send a separate signal to a subwoofer crossed over at 200Hz or lower, since the timing requirements are much less severe. This means you can have a stereo pair and multiple distributed subwoofers and all can receive their own dedicated audio stream.
Also, I don't multicast because that doesn't work with WiFi. Instead I use multiple unicast streams.
As for latency, that is a whole separate issue. In my application it could not be lower than a few tens of milliseconds (e.g. 30msec). I often operated at around 100msec just to make sure the buffer on the RX end of the transmission did not run dry. Several other buffers (send, processing, DAC buffering) all meant the total end-to-end latency was often 500msec or more. Since I used my system only for distributed music playback I didn't care about the total latency all that much, but this would be totally unacceptable for audio+video use. I am sure that there are lower latency hardware based systems, but I like to code and so I DIY'd a home-brewed system.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.