3 ms·

Remember that networks introduce latency. It might be tiny but the human ear can detect speakers being _slightly_ off. For example you wouldn't want a wifi spe

by mike_d 4y ago

Remember that networks introduce latency. It might be tiny but the human ear can detect speakers being _slightly_ off. For example you wouldn't want a wifi speaker in an elevator using a repeater at the top of the shaft trying to match up to a hardwired speaker in a ground floor vestibule.

9dev 4y ago
Modern wifi speakers can be configured with variable drift for the playback to mitigate this very issue :)
joshvm 4y ago
Does network latency dominate over speed of sound? Propagation time is about 3ms / metre in open air.
- anyfoo 4y ago
  It basically does not matter if you sync your clocks via NTP and play back accordingly.
anyfoo 4y ago
You can use NTP to get the devices' clocks synced up to much better than necessary tolerance, and play back accordingly. And then you "just" have the same problems that you have with purely electrically connected, analogue speakers (which are effectively 100% in sync in terms of receiving the signal): Sound is relatively slow, and so the audio from a speaker that is far away will reach you later than the nearby speaker. You can mitigate that by adding a precise delay to the far away speaker... but of course that does not work if you're standing on the other side. Nevertheless, as said, that problem is regardless of whether your speaker is network-connected or not.
- thfuran 4y ago
  You just need to take a cue from wifi and use beam forming to send separately synced audio to each person.
- error503 4y ago
  Kind of. The bigger problem you will have if you try this is that the audio is not clocked by the system clock, and the audio clock is almost always free-running (and even if it were derived from the system clock, NTP et al don't generally discipline the clock itself, just the OS's presentation of it). So in the case of a long running playback (or continuous, as in this case), you will drift out of sync over time, and it doesn't take that long to become noticeable. And at some point you'll either start dropping out due to either buffer underflow or buffer overflow. So you do still need to take care about this. So to work well you do need to resync the audio to the local audio clock using a sample rate converter, or build some custom hardware that lets you sync the playback audio clocks somehow. Or if you want to be sloppy about it, keep close track and stuff or drop individual samples as you drift. But yeah, this is all more or less 'solved'.
  - anyfoo 4y ago
    True, it was definitely simplified. But yeah, in cases where you really care, there's a bunch of options to do it completely/sufficiently in sync. (A true asynchronous sample rate converter, as it would have to be here, might be a bit expensive, but simple interpolation, or even stuffing/dropping, might be sufficient for this particular use case.)
  - ryanianian 4y ago
    Sonos has a remarkably good implementation of all of this. For URL-based streams they buffer and NTP to sync. For live streams (e.g. gaming) they p2p multicast and tweak the wifi params in real-time to minimize drops. The speakers create their own wifi and use MST network heuristics to latency-min route over that versus native wifi or ethernet if you've plugged it in. Sound drops when the wifi spectrum blinks (rarely), but I have never encountered the speakers being out of sync or noticing an echo effect. And the speakers can use your phone's mic to scan the soundscape of a room to acoustically balance the sound when you set them up. I particularly like how consistent the sound volume is room-to-room even with very different speaker setups. IIRC they've patented their specific mechanism. So ya, it's solved, but it may be expensive to license. (Not affiliated with Sonos, I just have a bunch of them and like them a lot.)
hot_gril 4y ago
I don't know much about audio encoding, but do the speakers not have to buffer the incoming packets? Large enough buffer size would introduce drift between speakers even if everything is fine network-wise.
- anyfoo 4y ago
  Just make sure they have a large enough buffer, and buffer enough, so that all speakers can play the same frames at the same time (or with the exact delay you want for each specific speaker). You only care about delay between the speakers, not about what latency any speaker has relative to the source.
  - hot_gril 4y ago
    Ah, that works. I also didn't know NTP was precise enough for this. Cool.
- error503 4y ago
  A fairly typical and simple approach is to set an intentional, fixed delay, say 500ms, to absorb network latency / inconsistency. The sender sends a target playback timestamp ~500ms in the future with each block of audio. Then the actual delay at the playback side can expand or contract as necessary to take up network delay. The lower you make this delay, the more care you need to take on the network side to guarantee timely delivery. NTP is accurate enough for this, but I think most of the modern protocols in the wild e.g. AES67, AirPlay2 are using PTP. It is both more accurate and in some ways simpler for this use case.

by mike_d 4y ago

9dev 4y ago

Modern wifi speakers can be configured with variable drift for the playback to mitigate this very issue :)

joshvm 4y ago

Does network latency dominate over speed of sound? Propagation time is about 3ms / metre in open air.

anyfoo 4y ago
It basically does not matter if you sync your clocks via NTP and play back accordingly.

anyfoo 4y ago

You can use NTP to get the devices' clocks synced up to much better than necessary tolerance, and play back accordingly. And then you "just" have the same problems that you have with purely electrically connected, analogue speakers (which are effectively 100% in sync in terms of receiving the signal): Sound is relatively slow, and so the audio from a speaker that is far away will reach you later than the nearby speaker. You can mitigate that by adding a precise delay to the far away speaker... but of course that does not work if you're standing on the other side. Nevertheless, as said, that problem is regardless of whether your speaker is network-connected or not.

thfuran 4y ago
You just need to take a cue from wifi and use beam forming to send separately synced audio to each person.
error503 4y ago
Kind of. The bigger problem you will have if you try this is that the audio is not clocked by the system clock, and the audio clock is almost always free-running (and even if it were derived from the system clock, NTP et al don't generally discipline the clock itself, just the OS's presentation of it). So in the case of a long running playback (or continuous, as in this case), you will drift out of sync over time, and it doesn't take that long to become noticeable. And at some point you'll either start dropping out due to either buffer underflow or buffer overflow. So you do still need to take care about this. So to work well you do need to resync the audio to the local audio clock using a sample rate converter, or build some custom hardware that lets you sync the playback audio clocks somehow. Or if you want to be sloppy about it, keep close track and stuff or drop individual samples as you drift. But yeah, this is all more or less 'solved'.
- anyfoo 4y ago
  True, it was definitely simplified. But yeah, in cases where you really care, there's a bunch of options to do it completely/sufficiently in sync. (A true asynchronous sample rate converter, as it would have to be here, might be a bit expensive, but simple interpolation, or even stuffing/dropping, might be sufficient for this particular use case.)
- ryanianian 4y ago
  Sonos has a remarkably good implementation of all of this. For URL-based streams they buffer and NTP to sync. For live streams (e.g. gaming) they p2p multicast and tweak the wifi params in real-time to minimize drops. The speakers create their own wifi and use MST network heuristics to latency-min route over that versus native wifi or ethernet if you've plugged it in. Sound drops when the wifi spectrum blinks (rarely), but I have never encountered the speakers being out of sync or noticing an echo effect. And the speakers can use your phone's mic to scan the soundscape of a room to acoustically balance the sound when you set them up. I particularly like how consistent the sound volume is room-to-room even with very different speaker setups. IIRC they've patented their specific mechanism. So ya, it's solved, but it may be expensive to license. (Not affiliated with Sonos, I just have a bunch of them and like them a lot.)

hot_gril 4y ago

I don't know much about audio encoding, but do the speakers not have to buffer the incoming packets? Large enough buffer size would introduce drift between speakers even if everything is fine network-wise.

anyfoo 4y ago
Just make sure they have a large enough buffer, and buffer enough, so that all speakers can play the same frames at the same time (or with the exact delay you want for each specific speaker). You only care about delay between the speakers, not about what latency any speaker has relative to the source.
- hot_gril 4y ago
  Ah, that works. I also didn't know NTP was precise enough for this. Cool.
error503 4y ago
A fairly typical and simple approach is to set an intentional, fixed delay, say 500ms, to absorb network latency / inconsistency. The sender sends a target playback timestamp ~500ms in the future with each block of audio. Then the actual delay at the playback side can expand or contract as necessary to take up network delay. The lower you make this delay, the more care you need to take on the network side to guarantee timely delivery. NTP is accurate enough for this, but I think most of the modern protocols in the wild e.g. AES67, AirPlay2 are using PTP. It is both more accurate and in some ways simpler for this use case.