Cutting Live Broadcast Latency From 7 to 2 Seconds for a Group Chat App

How Fishjam handles compositing and broadcast

Fishjam takes the audio and video streams from all hosts and combines them into a single broadcast stream that can be delivered to viewers at scale. The key thing is that compositing isn't a separate service or a piece of custom infrastructure; it's built directly into the Fishjam platform.

Layouts, speaker tiles, VAD speaking outlines, avatars, names, mic/cam state, and even different broadcast and recording variants are configured in backend code, applied by Fishjam’s compositing service and distributed through its broadcasting capabilities.

For the ChatBCC team, this meant they didn't have to spend engineering time building and maintaining complex multimedia backend infrastructure. Instead, they could focus on developing more cool product features. With most of the heavy lifting handled by Fishjam, the integration is simple and lightweight while enabling low-latency, cost-effective live streaming at scale.

Working directly with the creators of the tool makes all the difference

Throughout the project, we worked closely with both the ChatBCC team and the Fishjam engineers, allowing us to iterate on the compositing capabilities that power Live Spaces.

When something didn't work, we could simply talk to the engineers building Fishjam and work through issues together. One example worth mentioning was conference room stability. After significant debugging, we traced the root cause to the SDK level – something that couldn't be patched from JavaScript. The fix ultimately required changes to the underlying WebRTC implementation and close collaboration with Fishjam's core team. That kind of access simply isn't available when you're a customer of a third-party platform.

Keeping four systems in sync

The Live Spaces feature has a lifecycle: green room, going live, multi-host transitions, recording, teardown. At every stage, API layer, Fishjam, the compositor, and the mobile app need to agree on what's happening, but in production, they don't always get the memo at the same time.

We noticed that some of the most challenging issues only surfaced under real-world conditions and were difficult to spot in development environments. For example, on iOS, moving the app to the background could permanently disable the camera due to differences in how production and development builds handled app lifecycle/state. In another case, an incoming alarm or phone notification at the exact moment a user joined a room could leave audio in a broken state.

We also investigated numerous reports of microphone failures that ultimately turned out to be caused by unexpected interactions with Bluetooth audio devices. Resolving these issues required analyzing how the application behaved across different devices, operating systems, and real-world user environments.

Many of these issues only surfaced under production conditions, which is why we dogfooded the feature internally, running team syncs through the app to uncover edge cases long before they reached users.