undefined | Better HN

0 pointsInitialLastName4y ago0 comments

To be clearer:

Yes, the headphones could store up N seconds of audio data ahead of playback. However, the value of buffering is that if you miss a chunk of data, you can tell the sender "give me that again". Protocols that allow buffering account for that by giving the data sink a means to tell the source "send me chunk F again". Bluetooth A2DP and other streaming protocols, because they prioritize constant latency over data reliability, don't have a means to allow that; the source keeps sending new chunks even if the sink didn't receive one.

As a result, there would be no value in headphones storing up a bunch of audio before playback; if a chunk is missing, there are no means to remedy that in the protocol, so it will still be missing when you play it back.

0 comments

1 comments · 1 top-level

kalleboo4y ago

> Bluetooth A2DP and other streaming protocols, because they prioritize constant latency over data reliability, don't have a means to allow that; the source keeps sending new chunks even if the sink didn't receive one.

That's true for the Bluetooth Headset profile (the low quality one you get on calls), but A2DP goes over Bluetooth ACL[0] which resends dropped frames.

A2DP headphones do have a short buffer on the order of a second or whatever to deal with the jitter from retransmissions (and devices like an iPhone have the logic to delay the display of video appropriately to keep the audio in sync).

Now none of this allows for a whole song to be buffered though.

[0] https://en.wikipedia.org/wiki/Asynchronous_Connection-Less

j / k navigate · click thread line to collapse