> Why the hell can't you just tell the headphones to play from the phone and keep the laptop connected?
This is something that baffled me on Windows and MacOS, but I don't seem to experience on Linux/Android/iOS. Windows was particularly "greedy"; whenever you'd turn on your headphones it would attempt to steal the connection away (even booting other multipoint connections off). MacOS is slightly more graceful, but still hiccups when it initializes a new sound source and (for some godawful reason) launches iTunes for me. Thanks Apple.
On my FireTV and Linux desktop/laptop, they seem to have lazy-negotiation enabled by default. Turned-on devices will connect and acknowledge one another, but won't switch audio sources until the other device starts playing audio. I really think this ought to be the standard for all Bluetooth audio stacks.
(Note: this is a relatively recent development on the Linux side of things. Before PipeWire, it's Bluetooth audio stack was worse than Windows.)
It’s complicated, but basically, when audio is playing (I.e. new audio session) that’s when the BT headphones wake up. So you can get horrible initial delay (and missed audio in some configurations), unless you just broadcast a null signal to keep the connection alive.
I’m assuming that’s why all the popular USB “Bluetooth audio with aptX” all identify as an audio device and handle pairing etc. on their own. (Despite Windows’ stack having aptX support)
I've run into that before too, but I'm talking about the latency when an audio session is already running. There's a latency test in this review of the headphones I have: https://www.rtings.com/headphones/reviews/sony/wh-1000xm4-wi... It's actually worse than I remembered. The iOS latency is 38ms and the Windows latency is 5.5x longer at 212ms. It's bad enough that watching videos is very annoying because the sound is visibly out of sync, and if you look through the other rtings reviews, this is about average for Windows Bluetooth.
That's probably a large piece of it, considering Linux has a similar interface that would work just as well (MPRIS controls). I wouldn't be surprised if all of those implimentations used media data to determine connection priorities.
I haven't experienced the issue with iTunes starting on bluetooth connections, but some people pointed me to this project to deal with it: https://github.com/tombonez/noTunes
You can also set it to start something else (Spotify, whatever) instead
I'm personally just miffed that it's enabled by default. Reminds me of something Microsoft would do (Hey, I see you connected your headphones! Want to launch Groove Music?)
This is something that baffled me on Windows and MacOS, but I don't seem to experience on Linux/Android/iOS. Windows was particularly "greedy"; whenever you'd turn on your headphones it would attempt to steal the connection away (even booting other multipoint connections off). MacOS is slightly more graceful, but still hiccups when it initializes a new sound source and (for some godawful reason) launches iTunes for me. Thanks Apple.
On my FireTV and Linux desktop/laptop, they seem to have lazy-negotiation enabled by default. Turned-on devices will connect and acknowledge one another, but won't switch audio sources until the other device starts playing audio. I really think this ought to be the standard for all Bluetooth audio stacks.
(Note: this is a relatively recent development on the Linux side of things. Before PipeWire, it's Bluetooth audio stack was worse than Windows.)