7 ms·

The headphones and earbuds could easily and realistically incorporate a buffer today. How’s that being ignorant?

by orhmeh09 5y ago

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.
  - chrisseaton 5y ago
    So the upload speed per song is real-time? Come-on - this conversation has turned silly.
    - necovek 5y ago
      BT 3.0 offered up to 24Mbps bandwidth, with other variants offering up to 3Mbps. CD quality music is 1.4Mbps. If you cannot come up with an error correcting scheme that will let you upload music in real time with those parameters, what parameters would you need? (And sure, these rates are hard to achieve with BT in real world because of varying distance and interference, and yes, CD quality music is not the highest quality encoding you can use, but you can achieve similar or better quality with less bandwidth too) And let's not forget this was a discussion of buffering. A buffer of 5 minutes (50MiB) buys you 5 minutes of not having to be real-time, or to be slowly lagging behind — if that covers 3h of continuous listening time, you probably covered 99% of uses where latency is not a big deal anyway (like playing music — calls and movies are another game). I already acknowledge practical UX problems with just relying on buffering, but it doesn't make much sense to say how it can't be done because of the protocol either.
      - 5y ago
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

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.
- chrisseaton 5y ago
  So the upload speed per song is real-time? Come-on - this conversation has turned silly.
  - necovek 5y ago
    BT 3.0 offered up to 24Mbps bandwidth, with other variants offering up to 3Mbps. CD quality music is 1.4Mbps. If you cannot come up with an error correcting scheme that will let you upload music in real time with those parameters, what parameters would you need? (And sure, these rates are hard to achieve with BT in real world because of varying distance and interference, and yes, CD quality music is not the highest quality encoding you can use, but you can achieve similar or better quality with less bandwidth too) And let's not forget this was a discussion of buffering. A buffer of 5 minutes (50MiB) buys you 5 minutes of not having to be real-time, or to be slowly lagging behind — if that covers 3h of continuous listening time, you probably covered 99% of uses where latency is not a big deal anyway (like playing music — calls and movies are another game). I already acknowledge practical UX problems with just relying on buffering, but it doesn't make much sense to say how it can't be done because of the protocol either.
    - 5y ago

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