5 ms·

Another question. Why aren't my bluetooth headphones better at buffering larger amounts of data. I should be able to load a complete song without skipping with

Another question. Why aren't my bluetooth headphones better at buffering larger amounts of data. I should be able to load a complete song without skipping with interference.

chrisseaton 5y ago
The protocol doesn’t support that - it’s streaming audio.
- marginalia_nu 5y ago
  Why wouldn't a streaming audio protocol allow for that?
  - chrisseaton 5y ago
    I don’t know if you understand what ‘streaming’ means? Streaming doesn’t support large buffering… because that’s not streaming. But more broadly, not everything can be in scope. At the time of design having 10 MB and a decompressor in earbuds wasn’t realistic. But blaming your headphones is ignorant - the headphones implement a protocol. They don’t have control over the protocol.
    - orhmeh09 5y ago
      The headphones and earbuds could easily and realistically incorporate a buffer today. How’s that being ignorant?
      - chrisseaton 5y ago
        The protocol doesn’t support that. The headphones can do nothing about that.
        orhmeh09 5y ago
        Why can’t the headphones buffer the sound for a second? Why would it need protocol support? I’m thinking something like anti-disk-skipping on portable CD players.
        PeterisP 5y ago
        If it's actually streaming, the buffer at headphones wouldn't help anything since any missed data would not get resent anyway (since the sender wouldn't keep a buffer and would not have any data to re-send) and would still cause a skip.
        chrisseaton 5y ago
        Was a full song, now it’s a second?
        orhmeh09 5y ago
        I only suggested a buffer, not one of an entire song length, so maybe you’ve mistaken me for someone. What I’m trying to figure out is why we can’t apply the same concept as in the anti skipping technology to Bluetooth cutouts.
        kalleboo 5y ago
        They already do keep a buffer for a second or so
        necovek 5y ago
        In theory, headphones could store music in a buffer instead of playing it, and then delay playing it by say 2 minutes (or 5 seconds or whatever). Even if existing BT profiles preferred losing quality, you could have BT headsets that pretend to be storage devices and accept file uploads and which then play them after they've been completely received. Ideally though, you'd use one of the BT profiles that already provide guaranteed lossless audio transmission (or develop one if there's none). In a sense, BT profiles are protocols within a protocol, so you can develop almost anything you want (ofc, you need devices to support those profiles too). Of course, the experience of clicking play on a song and having it only start a number of seconds later is not something that'd sell particularly well, I guess. And then you'd have to renegotiate the BT profile if a call comes in that has to happen live. And switching back to the song will have another big delay.
      - InitialLastName 5y ago
        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.
        kalleboo 5y 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 https://en.wikipedia.org/wiki/Asynchronous_Connection-Less
    - marginalia_nu 5y ago
      > But blaming your headphones is ignorant - the headphones implement a protocol. They don’t have control over the protocol. If the headphones are implementing a protocol that isn't suitable for purpose, there is very good reason to blame the headphones. What's the point in having headphones if you need to be in a Faraday cage to use them?
      - chrisseaton 5y ago
        If you buy Bluetooth headphones and complain they don’t buffer full songs then that’s your problem, not the headphones. > What's the point in having headphones if you need to be in a Faraday cage to use them? Surely it’s the opposite? They don’t work in a Faraday cage, because they’re streaming and need to be connected.
        marginalia_nu 5y ago
        > If you buy Bluetooth headphones and complain they don’t buffer full songs then that’s your problem, not the headphones. What is the use case for headphones that cut out every couple of seconds? > Surely it’s the opposite? They don’t work in a Faraday cage, because they’re streaming and need to be connected. In this case the broadcast source would be in the Faraday cage along with the listener.
    - Dylan16807 5y ago
      > I don’t know if you understand what ‘streaming’ means? Streaming doesn’t support large buffering… because that’s not streaming. That's not how those words work. Twitch is streaming, right? Under certain flaky playback conditions it can buffer a full minute. Which is 50 megabytes at full quality.
      - mrtweetyhack 5y ago
izacus 5y ago
Because that adds a massive amount of latency, something that is a no. 1 complaint for Bluetooth headphones.
- lxgr 5y ago
  This will change (hopefully) soon with Bluetooth LE audio!
colechristensen 5y ago
Because you might be unhappy if there were 30 second latency on a bluetooth voice call, and there would be a whole lot of overhead in an already complex protocol to enable buffered audio instead of live audio.
jtsiskin 5y ago
Imagine watching a movie with this. I believe apple actually does something like this, slightly delaying the video playback so the AirPods can buffer and the video stays in sync. But this only works if the video player and headphones can communicate.
- pjerem 5y ago
  In fact, Apple aren’t doing this alone. It’s a pretty common feature of video players. I’m pretty sure even VLC supports this.

Another question. Why aren't my bluetooth headphones better at buffering larger amounts of data. I should be able to load a complete song without skipping with interference.

chrisseaton 5y ago

The protocol doesn’t support that - it’s streaming audio.

marginalia_nu 5y ago
Why wouldn't a streaming audio protocol allow for that?
- chrisseaton 5y ago
  I don’t know if you understand what ‘streaming’ means? Streaming doesn’t support large buffering… because that’s not streaming. But more broadly, not everything can be in scope. At the time of design having 10 MB and a decompressor in earbuds wasn’t realistic. But blaming your headphones is ignorant - the headphones implement a protocol. They don’t have control over the protocol.
  - orhmeh09 5y ago
    The headphones and earbuds could easily and realistically incorporate a buffer today. How’s that being ignorant?
    - chrisseaton 5y ago
      The protocol doesn’t support that. The headphones can do nothing about that.
      - orhmeh09 5y ago
        Why can’t the headphones buffer the sound for a second? Why would it need protocol support? I’m thinking something like anti-disk-skipping on portable CD players.
        PeterisP 5y ago
        If it's actually streaming, the buffer at headphones wouldn't help anything since any missed data would not get resent anyway (since the sender wouldn't keep a buffer and would not have any data to re-send) and would still cause a skip.
        chrisseaton 5y ago
        Was a full song, now it’s a second?
        orhmeh09 5y ago
        I only suggested a buffer, not one of an entire song length, so maybe you’ve mistaken me for someone. What I’m trying to figure out is why we can’t apply the same concept as in the anti skipping technology to Bluetooth cutouts.
        kalleboo 5y ago
        They already do keep a buffer for a second or so
      - necovek 5y ago
        In theory, headphones could store music in a buffer instead of playing it, and then delay playing it by say 2 minutes (or 5 seconds or whatever). Even if existing BT profiles preferred losing quality, you could have BT headsets that pretend to be storage devices and accept file uploads and which then play them after they've been completely received. Ideally though, you'd use one of the BT profiles that already provide guaranteed lossless audio transmission (or develop one if there's none). In a sense, BT profiles are protocols within a protocol, so you can develop almost anything you want (ofc, you need devices to support those profiles too). Of course, the experience of clicking play on a song and having it only start a number of seconds later is not something that'd sell particularly well, I guess. And then you'd have to renegotiate the BT profile if a call comes in that has to happen live. And switching back to the song will have another big delay.
    - InitialLastName 5y ago
      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.
      - kalleboo 5y 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 https://en.wikipedia.org/wiki/Asynchronous_Connection-Less
  - marginalia_nu 5y ago
    > But blaming your headphones is ignorant - the headphones implement a protocol. They don’t have control over the protocol. If the headphones are implementing a protocol that isn't suitable for purpose, there is very good reason to blame the headphones. What's the point in having headphones if you need to be in a Faraday cage to use them?
    - chrisseaton 5y ago
      If you buy Bluetooth headphones and complain they don’t buffer full songs then that’s your problem, not the headphones. > What's the point in having headphones if you need to be in a Faraday cage to use them? Surely it’s the opposite? They don’t work in a Faraday cage, because they’re streaming and need to be connected.
      - marginalia_nu 5y ago
        > If you buy Bluetooth headphones and complain they don’t buffer full songs then that’s your problem, not the headphones. What is the use case for headphones that cut out every couple of seconds? > Surely it’s the opposite? They don’t work in a Faraday cage, because they’re streaming and need to be connected. In this case the broadcast source would be in the Faraday cage along with the listener.
  - Dylan16807 5y ago
    > I don’t know if you understand what ‘streaming’ means? Streaming doesn’t support large buffering… because that’s not streaming. That's not how those words work. Twitch is streaming, right? Under certain flaky playback conditions it can buffer a full minute. Which is 50 megabytes at full quality.
    - mrtweetyhack 5y ago

izacus 5y ago

Because that adds a massive amount of latency, something that is a no. 1 complaint for Bluetooth headphones.

lxgr 5y ago
This will change (hopefully) soon with Bluetooth LE audio!

colechristensen 5y ago

Because you might be unhappy if there were 30 second latency on a bluetooth voice call, and there would be a whole lot of overhead in an already complex protocol to enable buffered audio instead of live audio.

jtsiskin 5y ago

Imagine watching a movie with this. I believe apple actually does something like this, slightly delaying the video playback so the AirPods can buffer and the video stays in sync. But this only works if the video player and headphones can communicate.

pjerem 5y ago
In fact, Apple aren’t doing this alone. It’s a pretty common feature of video players. I’m pretty sure even VLC supports this.