A cool project, when you want to use AirPods outside of Apples ecosystem. Sadly, you have to use a rooted android device with a small patch due to a bug in the Android Bluetooth implementation.
https://issuetracker.google.com/issues/371713238
It doesn't seem obvious to me that this is actually a bug in the Android implementation, it seems like this is due to AirPods violating the spec and requiring a special handshake before responding to standard requests. It doesn't seem reasonable to expect Android to work around a device that appears to be intentionally breaking the spec for vendor lock-in purposes: the possibility of them just OTAing an update that breaks in some other way means that you'd have to be entirely bug compatible with iOS's bluetooth implementation.
It not that hard to imagine Apple going out of their way to do something that would break functionality on Android, honestly. Although, I believe Fluoride also is to be blamed here because a simple timeout can not possible cause any issues (it seems that a timeout is there, but never called- at least from my tinkering). I am not planning to spend a single second tracing back the actual problem and suggesting a fix, given that Google just asked me to reproduce twice (!!) and did nothing about it.
when you’ve worked long enough in any given industry you know that all companies "violate" standards to satisfy requirements of their product management.
Apple have been ‘extending’ the Bluetooth stack for quite awhile. They introduced some BLE features before the spec was finished (I think some 3rd party hearing aids were also compatible).
I haven’t used non apple earphones for awhile but the seamless connectivity performance of AirPods would suggest this was done for performance, not to deliberately lock in devices.
In general, rigidity of stack is a malfeasance. Over protecting the user brings fragility, un-adaptability, that curses the world. Android certainly is a rigid narrow protective stack that refuses to accommodate, again and again. Different genre, but decades latter and it still won't work on many ipv6 networks because for no clearly stated reason it won't support DHCPv6: Android is full of these weirdly unstated "principled" anti-compatibilities, and I can't excuse blaming the devices or networks for being what they are: it's the unbending rigid OS that offends me.
I do rather hope perhaps perhaps perhaps the EU & DMA or other may perhaps bend Apple off their rotten course of making non-standard bespoke systems. It seems like very recently the EU is getting ready to cave & abandon all their demands for trying to use standards, that their fear of the US is about to make them fold on insisting upon better. Demanding Apple stop doing everything in bespoke incompatible ways is something that should have happened a long time ago, imo, and it's so horrifying to see one of the only stands in my lifetime against the propeietarization & domination of systems by a bespoke corporate lord abandoned.
There's some rays of hope here & there. Seemoo Lab has a ton of amazing reverse engineering efforts, figuring out how many many many undocumented locked down Apple systems & protocols work & trying to give control back. This is the highest virtue, the best hacker nature. Here's Open Wireless Link, but they have so many other amazing projects they've similarly figured out out to pry open. Amazing best human spirit.
https://github.com/seemoo-lab/owl
is there evidence it’s for vendor lock in purposes? airpods have a pretty stellar connection for bluetooth, wouldn’t be surprised if there were performance reasons for them going off spec
Google works around a ton of out-of-spec hardware / driver quirks for Android's ExoPlayer media player stack. So it is more than reasonable to expect Google to add a workaround for this.
Any idea how much latency there is between the beginning of audio being played in an app, and it then coming out the headset?
I use wired headphones to study with Anki (AnkiDroid) because I've found most (inexpensive) Bluetooth headphones require a second or two to begin playing. As I'm dealing with short audio clips, this use case necessitates restarting the "audio playing" situation every few seconds.
Maybe the app developers could "play" quiet audio between these short clips. But barring such a development, I'd like to know if higher quality headphones might suffer from less latency in this regard.
> I use wired headphones to study with Anki (AnkiDroid) because I've found most (inexpensive) Bluetooth headphones require a second or two to begin playing.
1-2 seconds is an eon for audio latency so I guess something else is going on than anything BT related in the headphones. Unless you have particularly bad luck in what headphones you use.
FWIW, I use a variety of cheap and not so cheap BT headphones across multiple devices and apps including AnkiDroid and have not perceived any latency.
If switching to wired removes the latency then it does seem to indicate something in the BT stack of your device. I wonder if you experience the lag when using AnkiDroid + BT on another device.
This is your host idling the connection due to the silence. Just keep something playing (like a stream of almost-silence) on loop and you won't have this problem.
That's probably some sort of gate on your headphones that silences audio (by killing power to the amplifier circuitry) if it's below a threshold loudness level, to prevent users from hearing a hissing sound the cheap circuitry produces that is otherwise masked by other louder sounds. When gate opens again, it takes 1-2 seconds for the amplifier to power up completely.
It's not really hard to reverse engineer AirPods. Just watch the bluetooth communication between a mac and the AirPods, turn specific features on/off, see how it reacts, then replicate exactly. I wanted to do it myself but saw something like this already exists (librepods, previously called "Airpods like normal (aln)").
That is such a typical bug report to a large company. A user who spent a lot of time debugging and finding the root cause of an issue, and a few faceless peons at the large company spending a few minutes on it, realizing it’s not a priority, and abandoning it.
And not a small bug either. This large an interoperability issue and it takes a nerd not in the employ of Google to fix their shit? This is why Apple's vertical integration makes it one of richest companies in the world. Google's only up there because of their success in that one business of theirs.
I'm convinced it's impossible to implement the BT spec without MANY of these kinds of bugs popping up.
Apple mercy-killed Adobe Flash, we should be asking they do the same to Bluetooth. I'm sick of living in a reality where no one thinks to make something better. It has to be possible.
> Apple mercy-killed Adobe Flash, we should be asking they do the same to Bluetooth.
They won't, because it turns out Bluetooth is the best thing we have at "discover nearby devices". Guess how Apple TV/screen sharing detection, iPhone hotspot detection and configuration, AirDrop and a whole host of other features work without communicating via some cloud mothership? They are all using Bluetooth to do detection and negotiation to a high-bandwidth link!
Amongst widespread radio communication mechanisms, there are only NFC, Bluetooth and WiFi. NFC is sometimes used to provision wifi passwords, but it's short-range to the tune of a few cm tops. WiFi has discovery, but nothing in the protocol to make sure initial conversations cannot be eavesdropped, and low-power wifi stacks are hard to do, in contrast to Bluetooth with BTLE.
Mercy killed? Flash was great. There were so many inventive games and animations in that era. Apple didn’t mercy kill anything - they just removed a threat to their walled garden ecosystem using their anticompetitive position, but dressed it up as a security issue.
jmgao|3 months ago
itsnoone|3 months ago
baxtr|3 months ago
helsinkiandrew|3 months ago
I haven’t used non apple earphones for awhile but the seamless connectivity performance of AirPods would suggest this was done for performance, not to deliberately lock in devices.
This 2020 paper is great at breaking down some of the extensions: https://www.usenix.org/system/files/woot20-paper-heinze.pdf
jauntywundrkind|3 months ago
I do rather hope perhaps perhaps perhaps the EU & DMA or other may perhaps bend Apple off their rotten course of making non-standard bespoke systems. It seems like very recently the EU is getting ready to cave & abandon all their demands for trying to use standards, that their fear of the US is about to make them fold on insisting upon better. Demanding Apple stop doing everything in bespoke incompatible ways is something that should have happened a long time ago, imo, and it's so horrifying to see one of the only stands in my lifetime against the propeietarization & domination of systems by a bespoke corporate lord abandoned.
There's some rays of hope here & there. Seemoo Lab has a ton of amazing reverse engineering efforts, figuring out how many many many undocumented locked down Apple systems & protocols work & trying to give control back. This is the highest virtue, the best hacker nature. Here's Open Wireless Link, but they have so many other amazing projects they've similarly figured out out to pry open. Amazing best human spirit. https://github.com/seemoo-lab/owl
a13n|3 months ago
alickz|3 months ago
Though I wonder why it works with Linux, which I assume doesn't have code for a special handshake specific to AirPods
jorvi|3 months ago
dotancohen|3 months ago
I use wired headphones to study with Anki (AnkiDroid) because I've found most (inexpensive) Bluetooth headphones require a second or two to begin playing. As I'm dealing with short audio clips, this use case necessitates restarting the "audio playing" situation every few seconds.
Maybe the app developers could "play" quiet audio between these short clips. But barring such a development, I'd like to know if higher quality headphones might suffer from less latency in this regard.
frumiousirc|3 months ago
1-2 seconds is an eon for audio latency so I guess something else is going on than anything BT related in the headphones. Unless you have particularly bad luck in what headphones you use.
FWIW, I use a variety of cheap and not so cheap BT headphones across multiple devices and apps including AnkiDroid and have not perceived any latency.
If switching to wired removes the latency then it does seem to indicate something in the BT stack of your device. I wonder if you experience the lag when using AnkiDroid + BT on another device.
AshamedCaptain|3 months ago
jesprenj|3 months ago
KolibriFly|3 months ago
worldsavior|3 months ago
WithinReason|3 months ago
> Need fix please
> original engineers got laid off thats why
cbsks|3 months ago
netsharc|3 months ago
almostgotcaught|3 months ago
[deleted]
fragmede|3 months ago
Andrex|3 months ago
Apple mercy-killed Adobe Flash, we should be asking they do the same to Bluetooth. I'm sick of living in a reality where no one thinks to make something better. It has to be possible.
mschuster91|3 months ago
They won't, because it turns out Bluetooth is the best thing we have at "discover nearby devices". Guess how Apple TV/screen sharing detection, iPhone hotspot detection and configuration, AirDrop and a whole host of other features work without communicating via some cloud mothership? They are all using Bluetooth to do detection and negotiation to a high-bandwidth link!
Amongst widespread radio communication mechanisms, there are only NFC, Bluetooth and WiFi. NFC is sometimes used to provision wifi passwords, but it's short-range to the tune of a few cm tops. WiFi has discovery, but nothing in the protocol to make sure initial conversations cannot be eavesdropped, and low-power wifi stacks are hard to do, in contrast to Bluetooth with BTLE.
yard2010|3 months ago
SilverElfin|3 months ago