OpenAI Build Week

OpenAI Build Week · Apps for Your Life · 2nd place

AirBridge for Windows

Built by Adam Tarantino

A Windows-to-AirPlay audio bridge with a file-free streaming path and a policy-gated assistant in the code. Speaker alignment is implemented, but we did not test it on hardware.

I also participated in this hackathon with Trajectory. This coverage was prepared independently after results were announced.

The idea worth stealing

When the protocol won’t tell you, ask the room.

AirPlay’s RAOP path never reports how late the sound arrives, so AirBridge stops asking. It plays five short chirps through the speaker, listens with the PC’s own microphone, takes the median, and trims each receiver by what it heard. The same instinct runs through the project: the builder reports checking the audio path with a microphone and an FFT; we did not reproduce the hardware run.

What we checked

Date checked: .

Submission code, CI and builder logs, plus Python and extension tests; no Windows or AirPlay hardware run.

Labels apply to each finding and the evidence described, not to the project as a whole.

Not independently verified means the available evidence was insufficient to confirm a claim. It does not mean the claim is false.

  1. The streaming path really is file-free

    Verified

    WASAPI loopback feeds a normalizer, a bounded in-memory ring, and a per-user Windows named pipe; a Python host opens that pipe as a pyatv audio source. Nothing in the path writes a file. Source

  2. The assistant is fenced by a local allowlist

    Verified

    Every tool the model can call is labeled read-only, reversible, confirmation-required, or forbidden in a static catalog checked before anything runs. gpt-5.6 reasons, gpt-4o-transcribe transcribes, and tests keep receiver identifiers out of the model’s view. Source

  3. Five chirps, and the median wins

    Partially verified

    The sequence is exactly five 90 ms chirps at 800 ms intervals, and the measurer refuses a result unless all five are heard. The builder’s log shows one live run at 1666, 1646, 1650, 1644, and 1647 ms. We could not measure. Source

    What we need: An independent Windows-to-AirPlay hardware test with all five chirp timings and the resulting median.

Under the hood

A named pipe crosses the language boundary
C# captures and normalizes to 44.1 kHz; Python reads the pipe as a pyatv AudioSource. The first hardware run exposed that pyatv swaps 16-bit words before transmission, which the custom source had bypassed. Golden-vector tests now pin the fix.
The extension delays the picture, not the sound
It copies video frames into a canvas overlay and paints each one after the measured delay, buffering up to 450 frames, while the page’s audio keeps playing. The overlay follows fullscreen and YouTube’s player container.

Nuance

None of this ran on Windows or against an AirPlay receiver here; the streaming claims rest on code reading, a green Windows CI at the submission commit, the Python and extension tests we did run, and the builder’s own logs. Alignment corrects constant latency across independent RAOP sessions; it is not AirPlay 2 multi-room with a shared clock, and the README says so. At submission the hardware tests quietly passed without hardware; the builder fixed that in September.

Sources

Last updated: . Editorial updates do not imply a new technical check.

Builder credits reviewed: , using the official announcement, submission, and any linked credit sources.

Builder? Add context, request a correction, or ask for a re-check →