Corey James- 91,643audio buffers through the soak, zero receive stalls and zero reconnects
- 50.001buffers a second against the SDK's 20-millisecond cadence
- 8,833buffers through a forced mid-call reconnect, with one 250 ms retry
- 65–67 msmedia round trip on one probe
A media-only bridge on Windows
Helix runs its speech models and conversation engine on Linux GPUs I own, and Microsoft Teams hands raw call audio only to a Windows application built on Microsoft's real-time media SDK. I refused to send call audio to a hosted AI service to avoid that mismatch, so I built a bridge and kept the brain at home.
The bridge is a .NET 8 solution of six projects (host, calls, media, transport, contracts and unit tests) on a Microsoft Azure Windows machine. Its only job is media: join the call, receive and send audio frames, and publish the agent's screen as video. Every decision stays with the engine on Linux, so the Windows side can be replaced without touching the AI.
Holding the SDK's memory and timing rules
The SDK is a preview package with strict terms. It hands out unmanaged audio buffers with exact lifetimes and expects audio on a 20-millisecond cadence. My send path allocates and frees that memory under the SDK's ownership rules.
When the slots fill, the network side waits; a paced pump drains one frame per tick.
A missed pace: the call stutters.
A buffer freed outside the SDK's rules: the process ends.
One authenticated link per call
Two Communications clients share one native media platform: the employee identity answers, and a transport-only client owns the media session. Audio reaches Linux over a purpose-built binary link on one authenticated WebSocket per call, implemented in C# and in Rust and tested byte for byte against shared golden vectors before either side is trusted. Screen share publishes H.264 frames from a headless Linux desktop through the SDK's video-based screen-sharing path.
I made a long soak and a forced mid-call reconnect requirements from the start. If the link breaks, the bridge reconnects inside the same call and drops the microphone audio captured during the break. The full account is A self-hosted colleague in a Teams call.
A colleague who answers a question from twenty seconds ago is worse than one who asks you to repeat it.
Leaving voice isolation to Teams
Inside Teams calls I rely on the platform's voice isolation and leave the engine's own speaker filter off, and I wrote down when that choice should flip.
I can work inside a vendor's preview real-time media stack under its memory and timing rules and join it to a Linux system across clouds, testing failure before success. Microsoft's SDK and media runtime are used unmodified; the service on top, the wire link and the reconnect behaviour are mine.