We also get latency improvements through Isochronous Adaptation Layer (ISOAL) Enhancement. This allows the Bluetooth device to cut larger data frames into smaller chunks while ensuring its timing information remains accurate. This would help reduce latency and potentially make Bluetooth audio devices a viable solution for wireless audio, especially in gaming.
That was unnecessarily snarky, but I couldn’t help myself. I don’t even know what any of that means or if it will actually actually reduce audio latency.
The “especially in gaming” bit is encouraging. That might mean they are finally, after 26 years, addressing the demand for good quality, low latency, multichannel, full duplex audio…
…but I won’t hold my breath. They seem to think gaming means playing on hardware like this.
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.
audio latency when
When you read the article:
That was unnecessarily snarky, but I couldn’t help myself. I don’t even know what any of that means or if it will actually actually reduce audio latency.
The “especially in gaming” bit is encouraging. That might mean they are finally, after 26 years, addressing the demand for good quality, low latency, multichannel, full duplex audio…
…but I won’t hold my breath. They seem to think gaming means playing on hardware like this.
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.
It’s a bit delayed
I see what you did there.
A major improvement already happened in 5.2+ but few devices support it yet (LE Audio with LC3 codec).
Will the isochronous mode improvements help?