4 ms·

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.
    - chrisseaton 5y ago
      But the protocol just doesn't support sending audio faster than it's supposed to be played. The sender doesn't know what to send to do what you want. There's no mechanism to do what you want for the headphones.
      - Dylan16807 5y ago
        Sure, the current protocol doesn't support it. But wanting a better protocol isn't 'silly'.

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.
  - chrisseaton 5y ago
    But the protocol just doesn't support sending audio faster than it's supposed to be played. The sender doesn't know what to send to do what you want. There's no mechanism to do what you want for the headphones.
    - Dylan16807 5y ago
      Sure, the current protocol doesn't support it. But wanting a better protocol isn't 'silly'.