Bluetooth multipoint flakiness, silent audio, and market failures

<scratchpad> [Rolling Structure: Opening B (Empirical Suspicion), Body B (Escalating Systems Diagnosis), Closing A (Sociological/Incentive Reframe) + B (Infinite Appendix)] </scratchpad>

For a while now, I've suspected that my Bluetooth headphones are getting significantly worse at switching contexts between my phone and my laptop. If you look at discussions online, like this Hacker News discussion thread, the default cocktail-party assumption is that Bluetooth is inherently a garbage protocol and multipoint hardware is flaky by nature. As a general principle, I assume human perception regarding hardware decay is inaccurate and physical components are usually more robust than people think, and if you look at system traces of the macOS audio daemon, coreaudiod, during these exact switching failures, you can see what is actually happening on the bus. It turns out the audio daemon is just explicitly locked by the web browser.

As documented in the original Laserphile blog post that tracked down this anomaly, the logs clearly show the daemon is intentionally kept awake by a Chrome helper process. A minimized background tab continuously executes collina.js and holds an active audio channel open by pumping empty buffers into it.

# Sequence of a Bluetooth Multipoint Failure
Background Tab (collina.js) -> Instantiates real-time AudioContext()
Browser Engine -> Flags tab as active media (bypasses CPU throttle)
OS coreaudiod -> Locks global audio channel (prevents hardware sleep)
Headset -> Receives incoming phone call, queries laptop audio state
Laptop -> Reports audio playing (due to 0x00 silent stream)
Headset -> Rejects context switch to phone

The actual mechanism here involves exploiting the Web Audio API specification. If an adtech vendor wants to fingerprint your device, standard practice is to use an OfflineAudioContext, which renders an audio graph as fast as the CPU allows directly into memory without touching the physical audio hardware—which makes it highly efficient for generating a unique hardware hash without creating side effects that the user would notice. But when analyzing telemetry logs that measure the CPU and battery cost of the silent collina.js tracking script over time, the metrics demonstrate that these sites are deliberately instantiating real-time Web Audio API streams and intentionally pumping zeroes into them.

And if you ask why a shopping site needs to stream silence to you forever, the answer maps perfectly to standard corporate misaligned incentives. Chrome and Safari aggressively throttle background tab CPU cycles to preserve battery life. If your tracking telemetry script is buried in a minimized window, the browser's completely reasonable CFS bandwidth scheduler will choke your JavaScript execution to a fraction of a percent. Modern browsers typically limit setTimeout and setInterval to run at most once per second in background tabs, and they significantly delay requestAnimationFrame calls. For a telemetry script trying to measure granular user interaction, tab visibility, or session duration, this OS-level throttling means you lose the resolution of your behavioral data.

So anyway, front-end engineers eventually discovered that playing a silent, real-time audio stream tricks the browser into categorizing the tab as active media, permanently disabling the background throttler.

When security researchers run profiling scripts against high-traffic retail and media sites, the resulting data logs resemble a deliberate denial-of-service attack on the user's power management controller rather than a standard sequence of page loads. Here is a simplified representation of the hardware state when these specific tabs are backgrounded:

Let's look at the raw math of what this normalization of deviance actually costs in physical resources. A locked coreaudiod state running continuous real-time buffer processing to prevent sleep adds roughly 1.2W of constant power draw to a modern laptop even when the screen is off. If a user leaves a tab running collina.js buried under other windows for a standard 8 hour workday (in a scenario where a user might literally just forget they have a shopping cart open three spaces away), the calculation is straightforward: 1.2W * 8h = 9.6Wh wasted.

Considering a standard 14-inch laptop has a 72.4Wh battery, we just take 9.6 / 72.4 = .132, meaning this single hidden background tab silently burns through 13.2% of your physical battery capacity per day just to guarantee its analytics payload fires on schedule. That's a massive pile of hardware <abbr title="which is deeply ironic considering these same adtech and media companies will publish extensive engineering blogs about their commitment to green computing">lit on fire</abbr> just to circumvent an OS-level power constraint.

If we scale this up to a modest user base of, say, 10 million active daily users who leave the tab open in the background for just 4 hours a day, the aggregate math gets deeply grim. You're looking at 1.2W * 4h * 10,000,000 = 48,000 kWh of electricity burned globally per day, solely to ensure telemetry pings hit a Kafka queue with sub-second accuracy instead of one-second accuracy.

Technical failures are almost always trivial compared to the organizational dysfunctions that cause them. We have a front-end telemetry script literally holding a global hardware lock, which is a massive ops smell, but the frontend engineers implementing this bypass are just locally optimizing for their own metrics. If the browser throttles their data collection loop, their dashboard numbers drop, which puts them in a bad position during performance reviews. The cheapest workaround is to stream an empty audio buffer. The resulting costs—a dead laptop battery and Bose headphones that refuse to switch context to an incoming phone call—are entirely externalized to the end user.

The classic Econ 101 argument is that markets naturally route around this kind of user hostility because consumers will switch to better products. The problem with relying on the efficient markets hypothesis here is that the feedback loop is completely severed. No normal user knows how to run dtrace on their audio daemon to realize their headphones failing to switch is the fault of a minimized shopping tab from three days ago. Because the cause and effect are divorced by multiple layers of abstraction (the web engine, the OS audio daemon, the Bluetooth controller, the headset firmware), there is no economic penalty for the adtech companies. The system functions exactly as designed by the people holding the purse strings.

If you were to ask someone abstractly if adtech companies want to break your Bluetooth headphones and drain your battery, I suspect they'd tell you no. But insofar as a market can be said to want anything, it wants what it incentivizes—and right now, invisibly offloading the compute cost of tracking loops onto your physical hardware carries a price of exactly zero dollars.

Appendix: Why Browser Vendors Won't Fix This

The strongest counter-argument to this entire situation is that Apple and Google should just permission-gate the WebAudio API the same way they gate microphone or webcam access. Just pop a dialog box asking users if they want to allow the site to play audio. This seems obvious until you look at the bureaucratic gridlock and technical debt of the web platform.

Backwards compatibility for browser gaming: Browser-based gaming relies entirely on immediate, user-interaction-triggered AudioContext generation. If you gate this behind a permission prompt, thousands of legacy web games will break because their sound engines initialize before the user explicitly clicks a start button (in that the engine requires the context to pre-load assets into the buffer before the first frame renders).
The computational cost of detecting silence: Distinguishing a legitimate silent audio buffer from a hostile tracking hack is computationally expensive. Games frequently stream silent buffers during load screens or between tracks to prevent the hardware audio channel from sleeping, which avoids a 200ms pop/crack latency penalty when the next sound effect fires. Building a heuristic to figure out if silence is malicious requires continuous monitoring of the buffer output, which ironically burns more CPU cycles.
Standard committee gridlock: The W3C standard committees are fractally contentious. Re-specifying a core API that has been widely deployed for a decade requires consensus among stakeholders who have wildly different incentives. Apple generally wants aggressive battery saving and strict privacy, while ad-heavy browser vendors are quietly fine with telemetry running unthrottled as long as it doesn't cause a direct browser crash.
The Whack-a-Mole API problem: Even if you successfully nuke the AudioContext workaround, the incentive to bypass background throttling remains mathematically infinite for tracking companies. Historically, when browsers patch one loophole, adtech just migrates to another. In the past, companies have used hidden WebRTC data channels to keep tabs active, or exploited the Battery Status API to track device decay signatures until that API was deprecated. As long as local optimization rewards highly granular telemetry, the engineers will just find the next OS-level primitive to hold hostage.