My layman’s understanding (so please correct me if I’m wrong) is that BT audio works by taking the audio stream from your playing device, and breaks up pieces of that stream into small packets. These packets get sent individually to your speaker, which then plays them all seamlessly in order as they flow in. But because these packets have to be cut out from the main stream in the first place before they can be sent, you’re always hearing something from just a few moments ago, as you can’t start playing a packet until it’s finished playing and transferring from the main device, first.
So by breaking these packets up into smaller pieces, you’re reducing how far back your speaker is, chronologically-speaking. So let’s just say that the current version of BT breaks up audio into 0.5-second increments (it doesn’t, this is just an example). This means that every 0.5 seconds, your device snips a half-second of audio into a packet and sends it to your speaker, which then plays that packet. But the transfer takes time, too, so let’s say 0.25 seconds to send (again, just made-up numbers for the sake of explaining the concept). So everything your speaker would be playing in this situation would be, at minimum, 0.75 seconds behind. Not a huge deal for listening to music, but it quickly gets out of sync with video content.
So pretend the new BT version instead breaks up the original audio into 0.1-second increments. So instead of generating 2 packets every second, it’s generating 10. Even if we keep the same transfer rate of 0.25 seconds in mind, this reduces the delay from 0.75 seconds to 0.35, which puts the audio much closer into sync with video content.
Not bad, but you’re missing that the Bluetooth device can report audio latency back to the source so it can delay anything that needs to synchronize. In practice there’s half a dozen more buffers in between and a serious tradeoff between latency, noise sensitivity, and bandwidth.
My layman’s understanding (so please correct me if I’m wrong) is that BT audio works by taking the audio stream from your playing device, and breaks up pieces of that stream into small packets. These packets get sent individually to your speaker, which then plays them all seamlessly in order as they flow in. But because these packets have to be cut out from the main stream in the first place before they can be sent, you’re always hearing something from just a few moments ago, as you can’t start playing a packet until it’s finished playing and transferring from the main device, first.
So by breaking these packets up into smaller pieces, you’re reducing how far back your speaker is, chronologically-speaking. So let’s just say that the current version of BT breaks up audio into 0.5-second increments (it doesn’t, this is just an example). This means that every 0.5 seconds, your device snips a half-second of audio into a packet and sends it to your speaker, which then plays that packet. But the transfer takes time, too, so let’s say 0.25 seconds to send (again, just made-up numbers for the sake of explaining the concept). So everything your speaker would be playing in this situation would be, at minimum, 0.75 seconds behind. Not a huge deal for listening to music, but it quickly gets out of sync with video content.
So pretend the new BT version instead breaks up the original audio into 0.1-second increments. So instead of generating 2 packets every second, it’s generating 10. Even if we keep the same transfer rate of 0.25 seconds in mind, this reduces the delay from 0.75 seconds to 0.35, which puts the audio much closer into sync with video content.
Not bad, but you’re missing that the Bluetooth device can report audio latency back to the source so it can delay anything that needs to synchronize. In practice there’s half a dozen more buffers in between and a serious tradeoff between latency, noise sensitivity, and bandwidth.