This is one of the infuriating things to me too, yeah. On the one hand, Bluetooth is a horrifying mismash of all these special-purpose protocols rather than a generic pipe. But then, when I want to take advantage of the fact that it's not a pipe and that I'm shipping down prepared audio (rather than live audio), which is something one of these specialized protocols ought to be able to negotiate, suddenly Bluetooth is just a dumb pipe relative to this use case. It's the worst of both worlds.

If you want generic pipe there is always the serial port profile.

Somehow my Honda Odyssey buffers bluetooth audio for ~3 seconds. I had thought that the designers/developers were just inept because none of my other bt audio devices work this way. It never occurred to me that this could be considered a feature.

... no, I still think it's a bug.

UGH this is a problem with all Hondas before ~2014. Drives me nuts. It's even worse when using it with Google Maps since the audio is delayed.

Agreed. My 2008 Audi A8 had around 3s of buffering. If I pressed "next track", it would take 3s to respond. Parked and watching a video? Out of sync by 3s with audio. Definitely not a feature.

If it was buffered and you changed track on your phone, you would then have to wait 15-20 seconds for the track to change as it would playing from the buffer.

I guess if it was 2 seconds it might be more bearable.

I think OP meant to pre-send music and keep the next 15 seconds available locally. This way you can handle 15 seconds of interruption.

So, when you start streaming music, it starts playing immediately, but it tries to send data faster than it is played until you have a decent buffer. Obviously, this would only work for non-realtime things.

Not if it honored an "invalidate buffer" command.

Increase the size of the buffer to N > 1 songs and allow the device to tell the headphones to skip ahead in the buffer. If "next song prediction" is hard (e.g. the user is clicking around their library), support a device "burst push" mode that lets the device send the first M seconds of a song very quickly.

On a side note, it's interesting that this buffering problem is identical with switching channels on any streaming service, and that the buffering delay is a significant psychological barrier to moving around, and that traditional radio works really friggin' well for what it does.

Is it? The reason I ditched BT headset in favour of wired one was that, on my Linux desktop, it would over the course of an hour acquire ~1s of lag between video and audio. Could be fault of the Linux BT stack, but still, someone buffers audio somewhere.

You might be able to thank PulseAudio for that: https://bugs.freedesktop.org/show_bug.cgi?id=58746 From what I recall, with an unreliable enough Bluetooth connection it can easily hit tens of seconds of audio delay.

Bluetooth 5 is fixing a lot of these issues with Bluetooth audio. It'll be over BLE too, which is a simpler stack that'a less prone to issues than to old Bluetooth 2 based stack.

I'm waiting to buy wireless headset until they hit the market. Could take a while though.

Thats probably a problem with your headphones. I have the original JAMBOX by Jawbone and I can clearly see there is a delay (1 sec) between doing something a hearing it in the speaker. I suppose that is because of buffering.

It works like this on both iOS and Android devices.

I remember learning somewhere (perhaps a Podcasts discussion?) that Bluetooth headphones can tell the host device what their audio delay is. Given that information to host device can adjust video playback so that the sound syncs up perfectly. I know iOS is capable of this, I'd assume macOS is well.

So it depends on the headphones.

Of course that only helps with premade content. If you're playing a game the OS can't adjust the game for 200 ms of lag, everything is just going to be out of sync.

I've always wondered how that worked! When watching a movie on my Linux laptop, it automagically syncs, even with a very poor quality promotional BT speaker that says "this bud's for you!" every time it pairs.

I've tried 4 different headphones from 3 different vendors with 2 different smart watches (Moto 360 Sport, now Polar M600). I've had the same problem with all of them.

At least one of the headphones has been a very high quality LG (HBS900?). Oddly, I've had the best connectivity with a cheapo freebie headphone set that has audio so bad that I can't stand to use them..

> If BT audio could be buffered for 15-20 seconds, this would not be a problem.

My phone (or my car) does about 2 seconds of buffering, which is usually just enough -- however, it applies the buffer regardless and doesn't synchronize to any other content. So, using BT to try and watch any videos completely fails.

This is shit gear. My Bose QC35 stay connected to my macbook pro and iphone 7 50-60 feet away through multiple walls.

See my comment elsewhere here, I had a set of Outdoor Chips bluetooth speakers for my ski helmet that would cut out if I turned my head the 'wrong' way and I returned that garbage posthaste.

That would require ~1Mb of memory (or potentially more), also would be unfeasible for some applications (like phone calls)

Phone calls use a different Bluetooth profile, so that's largely irrelevant.

1 megabit (did you mean megabyte?) of memory is not worth noting. It could be integrated into the IC that contains the entire system for headphones quite easily. That system already has memory in there anyway.

1 Megabyte and your average BT audio device has less memory than you think

Standards have not been made considering today's availability of memory and resources

I'm not sure how much memory you think I assume is present. My point is that it would be a possible and simple extension, not that it is already present.

There is currently exactly as much memory as needed. That does not make it unrealistic to extend it with a buffer. Cheap SBC-only devices certainly won't do it as those are solely about cost optimization, but the beefier, pricier AAC/Apt-X multi-device capable bluetooth audio sink solutions that sell for premiums could easily incorporate a bit of extra memory. 1Mb (megabit) would give a few seconds of buffering, which would be sufficient. It'll take a bit more silicon, but nothing absurd. Hell, it could be external memory over SPI, so integrators could select buffering capability themselves, without significant cost/silicon area increase of the bt chipset

However, to actually utilize buffering, you'd need a higher bandwidth link than is required for live playback to catch up after connectivity dips. Buffering by itself only adds latency. The question is then whether you'd want to use your link bw for resilience of low quality audio, or instant high quality audio...

Usually far less than 1 MB. It's about cost, footprint and power consumption.

What profile is used for phone calls depend on configuration of the phone and the headset.

Last week I accidentally found out that I can use two phones at once with integrated HF in my car's radio as long as they use different BT profile (somewhat unsurprisingly, while trying to fix completely unusable sound quality over BT)

That's so you can have a music device and calling device connected simultaneously. Both connections can be consumed by one device if you want both music and call functionality.

I don't think your phone will try to use A2DP for a call.