The Audio Engine Behind Cerebyte: How SEM Nexus Solved a Three-Team Problem

Cerebyte is a wellness mobile app that plays audio derived from real EEG brain-activity recordings. Members wear an EEG headset, record a session, and the app generates and plays an audio composition shaped by their brainwaves. The product is unusual; the engineering behind it is unusual too.

What's less widely known is that three prior engineering teams attempted this audio engine before SEM Nexus took it on. Each team got partway. None shipped. When the founder brought the project to SEM Nexus, the question wasn't whether the audio could be done — it had been demonstrated in research conditions — but whether it could be done in a mobile app that runs reliably on both iOS and Android, with the latency and fidelity wellness listeners expect.

This is the technical story of how SEM Nexus solved it. Heavy positioning warning: this post is intentionally explicit about what made the SEM Nexus engineering work where three other teams stalled.

What "EEG-derived audio" actually means in production

In simplified terms: the app receives a recorded brainwave stream from the EEG headset, decomposes it into frequency bands, and uses those bands to drive parameters of a real-time audio engine — track selection, layering, modulation, tempo, harmonic balance. The output is a piece of music that varies because the brain recording varied.

The engineering hard parts:

Real-time audio mixing — the engine has to mix multiple audio tracks and apply per-band modulation, all without latency the user would perceive (sub-50ms target on the audio pipeline).
Cross-platform fidelity — the audio has to sound identical (or close to it) on iOS and Android. Cross-platform audio is notoriously where mobile engineering teams stall.
Background playback + alarm integration — the app supports a "Wake Up" alarm that plays a Cerebyte track. That means the audio engine has to survive backgrounding, OS audio session interruptions (calls, system alarms), and resumption.
Subscription gating — premium tracks behind a paywall, free tracks open. Receipts have to be reliable across platforms.
Audio library delivery — tracks are streamed, not bundled. The delivery layer has to handle network instability gracefully.

The three previous teams attempted this in three different ways. None landed.

What the previous teams tried

We have visibility into what went wrong because the founder shared the rebuilt-and-rebuilt history. Names redacted, but the shapes:

Team 1: native iOS + native Android, separate codebases. Pro: best audio APIs (AVAudioEngine on iOS, AudioTrack/Oboe on Android). Con: two audio engines to write, two codebases to keep behavioral-equivalent, two engineers to manage. The team shipped a working iOS prototype and stalled on Android — the implementation drift between the two engines couldn't be closed without a rewrite of one to match the other.

Team 2: React Native + native audio modules. Pro: shared UI codebase. Con: the audio engine itself still had to be written natively on both sides. The RN bridge added serialization overhead and made debugging the audio pipeline materially harder. The team got 70% of the way to a working iOS build and called it.

Team 3: Unity / cross-platform game engine. Pro: solved the cross-platform audio problem. Con: massive binary size, slow startup, and a UI rendering pipeline designed for games, not for a wellness app. The team shipped a working audio prototype but couldn't make the UX feel like a wellness app — it felt like a game.

Each team made a defensible stack choice. None of them was wrong in isolation. All three were wrong for the specific shape of Cerebyte.

The SEM Nexus call: Flutter + Dart FFI

When the project came to SEM Nexus, the senior engineer who would own the build sat in discovery from day one. The audio analysis happened in week 2.

The recommendation came down to one structural insight: the audio engine has to be written exactly once, in code the SEM Nexus team could maintain end-to-end. Anything else introduced enough divergence risk to repeat the previous failures.

The Flutter ecosystem in 2024 had matured enough on audio that:

just_audio provided the high-level playback layer
Dart FFI (foreign function interface) provided a clean path to call C-level audio libraries directly when Dart wrappers weren't fast enough
Flutter's audio session integration (via plugins like audio_session) handled background and interruption behavior on both platforms

The architectural plan: one audio engine written in Dart with FFI-bridged C primitives for the mixing-and-modulation hot path. Single codebase. Single language. Single mental model.

A 60-line audio proof-of-concept landed in sprint 1, before any UI work. It played back a real EEG-derived audio composition on a real iPhone running iOS. By the end of sprint 1, the hardest risk was retired.

Want the same risk-first approach applied to your project's hard part? SEM Nexus's two-week discovery names the hard part in writing and a real proof-of-concept (where the risk is high enough to need one) goes into sprint 1.

What the prior teams missed

In hindsight, the previous teams missed two structural things:

The hard part wasn't the audio itself — it was keeping it identical across platforms. Once you accept that, the stack decision changes. The team picks a stack that minimizes the cross-platform divergence surface, not a stack that maximizes platform-specific power.

Sprint 1 has to retire the highest risk. Two of the three previous teams polished UI and infrastructure in early sprints because that work felt productive. The audio engine — the actual hardest part — got pushed to month 3. By month 3, the team had committed enough to a stack and architecture that they couldn't easily change. SEM Nexus retires the highest risk first, every time. Other work waits.

The build that shipped

Cerebyte shipped to the App Store and Google Play Store in 14 weeks from SEM Nexus discovery kickoff. The audio engine measures within 5ms of native latency in production — well below human perception thresholds. The cross-platform divergence is functionally zero: iOS and Android users hear the same composition for the same EEG recording, frame-aligned to the source.

The wins downstream:

We hit a few rough patches with iOS's audio session interruption handling (calls, system alarms) and had to dig into the platform plumbing deeper than the Flutter abstraction wanted. That's normal — every mobile build has one platform-specific deep dive.
We never wrote a parallel engine. Every audio change ships on both platforms simultaneously, by construction.
Post-launch, the engine has been iterated on for new track layering features, new Wake Up alarm behaviors, and improved subscription handling — all without a rewrite.

One audio engine. Two platforms. 14 weeks. That's the engineering output that three previous teams couldn't produce.

What this means for your hard problem

If your project has a hard technical part that has stalled prior teams — audio, real-time, offline-sync, BLE, on-device ML, anything where the engineering risk is real and named — the SEM Nexus approach is structurally different from what you've probably seen before:

The senior engineer who'll own the architecture sits in discovery from day one.
The stack analysis is honest, cross-stack, and surfaces the right answer even when it's not the trendy answer.
The highest technical risk gets retired in sprint 1, not in sprint 8 when the project is already six months in.
The build follows the analysis — no quiet stack switch after the founder signs the quote.

If you'd like a similar analysis applied to your project's hard part, SEM Nexus's two-week discovery is the place to start. We name the risk in writing. We retire it before the budget is committed downstream. That's the structural reason we ship projects that three previous teams couldn't.