DEV Community: SleepTrace

The overnight audio ring buffer design that keeps 8 hours without spilling memory

SleepTrace — Mon, 10 Aug 2026 00:40:54 +0000

The overnight audio ring buffer design that keeps 8 hours without spilling memory

Recording audio all night sounds like a memory problem waiting to happen: 12.8 kHz mono at 8 hours is roughly 2.3 GB of raw PCM if you hold it all. No overnight app keeps 2.3 GB resident — it gets terminated. The design that works is a fixed-size ring buffer that holds only what the feature extractor needs, and a disciplined policy that overwrites the rest.

This is the exact ring buffer architecture SleepTrace runs in the background every night, and the one mistake that silently loses nights when it gets the timestamp anchoring wrong.

The ring, and why it must be fixed

The buffer is allocated once at session start: 4 seconds of 12.8 kHz mono int16 = 102,400 samples, ~200 KB. Each 2-second frame read out advances the read pointer by two seconds and the write pointer by two seconds. Because reads and writes move at the same rate, the buffer never grows.

If the frame rate ever exceeds the capture rate (the model stalls, the CPU is throttled), the write pointer laps the read pointer and you get buffer underrun — a tell-tale zero-gain region in the feature stream. That is the detectable signature of OS throttling, exactly the signal-quality flag you want to surface rather than hide. The full field notes on detecting those throttling gaps are here.

The two-clock trap

The bug that took the longest to fix: treating the audio clock (CMTime from AVAudioInputNode) and wall-clock time (Date) as synchronized. They are not. Over eight hours, the drift between them is enough that "the snoring cluster at 02:17" lands at 02:09 in local time, and suddenly the event-correlation pipeline that ties snoring hours to user-entered alcohol intake stops working.

The fix is an anchor: at session start, you capture a single paired sample (audioTime, Date.now()), and after every interruption you re-anchor. The feature log stores everything as offsets from the most recent anchor, converted to wall-clock only at export. The conversion code is the unglamorous core of the blog post on acoustic detection.

Discarding raw audio safely

At morning flush, the ring buffer is simply overwritten. No write-to-disk path exists for raw audio. The event log — timestamps, classes, confidence flags — is the only persistence, and it is a few hundred kilobytes. That discipline is what lets the app live in the background all night without the OS killing it for memory, and it is what makes the "audio never leaves your phone" promise provable in code, not just copy.

What a 40MB CoreML model actually detects in your bedroom audio

SleepTrace — Mon, 10 Aug 2026 00:40:22 +0000

What a 40MB CoreML model actually detects in your bedroom audio

A 40MB CoreML sleep model sounds ambitious until you realize the discriminative power in bedroom audio is concentrated in features that cost almost nothing to compute. The model's job is mostly to clean up edge cases the linear features already separate well. Here is what the model is really doing, layer by layer, and why it stays small.

The two-stage classifier

Stage one is a linear separator over six engineered features:

Spectral tilt slope over 0.5–4 kHz — snoring tilts down, speech tilts flat.
High-band zero-crossing density (4–16 kHz) — low for snoring, high for sibilants.
Harmonic-to-noise ratio in the 100–800 Hz envelope — snoring is strongly periodic.
Band energy ratio (low/mid) relative to the trailing 30-second baseline.
Spectral flatness — distinguishes aperiodic snoring bursts from tonal noise.
Temporal rise/fall asymmetry of the envelope — snoring ramps up slowly, speech transients sharply.

A logistic regression over these six features on-device matches a 200MB neural net on 87% of the validation set. The neural net is not smarter; it is just covering the confusion region.

The small net that earns its 40MB

The on-phone model is a 5-layer MLP with 128-width hidden layers, trained on 180k labeled 2-second frames from SleepTrace users (opt-in, all on-device labeled). Quantization to int8 brings it to 38 MB on disk. It runs in 1.8 ms per frame on the Neural Engine of an iPhone 13, which is the entire frame budget including feature extraction.

The model's job is a single classification head with a snooze/talk/ambient/apnea-pause four-way soft output, plus a confidence score that gates whether a frame participates in the smoothing pass. The full feature engineering rationale — why spectral tilt separates snoring from sentences, why harmonic structure separates voiced apnea gasps — is published on the engineering blog.

Why not just the linear model?

Two reasons:

Position-dependent false positives. HVAC rumble has low tilt and low harmonic content; it trips the linear model. The MLP learns a positional embedding over the night so HVAC rumble only scores as snoring when it sits between midnight and 04:00 with the right rhythm.
Confidence calibration. The MLP emits a calibrated confidence the smoothing pass uses to weight temporal consensus. Without it, every borderline frame either becomes a hard event or gets dropped entirely.

The size constraint is real

iOS throttles the resident memory of on-device CoreML models in background tasks. We hit that ceiling at ~45 MB resident; beyond it the queue stalls and the night develops silent gaps that look like quiet sleep. That is why the model architecture and the quantization scheme are co-designed around a 40 MB ceiling — and why on-device, unlike cloud, the size of the model is a correctness budget, not a performance budget.

Why consumer sleep accuracy is a trap (and what to measure instead)

SleepTrace — Mon, 10 Aug 2026 00:39:42 +0000

Why consumer sleep accuracy is a trap (and what to measure instead)

Sleep labs validate against polysomnography. Consumer sleep trackers validate against nothing stable — not other wearables, not consistent behavior across nights, not any external ground truth. The result is a market full of stage charts and sleep scores that agree with each other about 30% of the time, which means they agree with each other about nothing at all.

Chasing PSG accuracy in a consumer product is a trap, not because phones are inaccurate, but because accuracy is the wrong objective. The phone is measuring the wrong things entirely.

What a phone on the nightstand actually measures

Let that sink in: a phone is not a wrist device. Its accelerometers are stationary. Its microphone is an open air path into a room. Its sensor fusion is dominated by acoustics, not motion. A consumer phone sleep product is really an acoustic event detector, and every honest one should start there.

From an acoustic standpoint, the detectable events have stable, reproducible definitions:

Snoring episodes: an aperiodic broadband burst in the vocal-band envelope with spectral tilt falling off above 1.5 kHz.
Breathing pauses: a sub-baseline spectral flatness over a 10–30 second window in the 100–400 Hz band.
Positional shifts: detectable from the tilt sensor over the course of the night.

These are not proxies for sleep stages. They are real events with clinical correlates (snoring intensity correlates with sleep-disordered breathing; breathing pauses correlate with apnea).

The accuracy fallacy

If the goal is "match the lab EEG," a phone will fail — but so will a wrist device, because the correlation between actigraphy and EEG sleep stages is weak by construction. The question is not whether a phone matches a lab. The question is whether the acoustic events it detects correlate with outcomes users care about: morning fatigue, daytime sleepiness, partner-reported disturbance.

That is the metric worth measuring: outcome, not stage.

Measuring against outcomes

SleepTrace measures its own accuracy against a daily morning fatigue slider and a weekly partner-disturbance score — both self-reported. The acoustic event detection (snore duration, breathing pauses, position changes) is validated against those outcomes, not against PSG. The technical writeup of the acoustic feature set that supports this is on the blog.

For builders: stop benchmarking against the wrong bar

Stop optimizing for PSG alignment. Optimize for outcome correlation. Ship the events, ship the confidence, ship the gaps. Let the stage charts be the domain of devices that earn a medical predicate. A phone on a nightstand earns its keep by being honest about what it can hear — and what it cannot.

The three engineering constraints that define overnight audio on iOS

SleepTrace — Mon, 10 Aug 2026 00:39:02 +0000

The three engineering constraints that define overnight audio on iOS

Building an audio app that runs all night on an iPhone is not about picking the right model. It is about surviving three constraints that do not exist in normal app development:

The background task budget. iOS grants roughly 30 seconds of background runtime per activation. To run all night, the app must renew its assertion on a cadence shorter than the budget — or the OS throttles the audio queue and the night goes silent.
The microphone sharing policy. If another system service is using the mic, the app's AVAudioSession is interrupted. Over an eight-hour window, this is guaranteed to happen — and silent interruptions look exactly like quiet sleep stages.
The thermal ceiling. A sustained classifier that keeps a core warm all night triggers thermal throttling. On older devices, the phone will downclock aggressively mid-session, dropping windows of audio that the app then has to detect and flag as low-confidence.

These three constraints map directly onto the user experience: if you handle them honestly, the app returns an honest night with honest gaps. If you ignore them, the app returns a fabricated night that looks complete.

Budget renewal done right

The renewal handler must be cheap and fast, because it runs under the expiry deadline. The correct shape:

bgTask = UIApplication.shared.beginBackgroundTask { [weak self] in
    self?.flushPendingBuffers()     // finish the in-flight window only
    self?.signalLowConfidence()     // mark the tail of the night
    UIApplication.shared.endBackgroundTask(bgTask)
}

The renewal itself (scheduling the next window) happens in the main audio callback, not in the expiry handler. The expiry handler only closes the current buffer cleanly. This is the exact problem the SleepTrace audio engineering notes walk through, including the drift-corrected timestamp anchoring used to avoid the gaps becoming data-integrity lies.

Microphone interruptions are features, not bugs

An interruption fires AVAudioSession.interruptionNotification. The naive response is to resume immediately. The correct response is to log the gap and lower confidence on the surrounding windows, because the microphone may have switched devices or picked up a different sound field after reconnection. Users get a morning note: "confidence reduced from 01:23–01:25 — likely a mic handoff." That is the honest signal-quality view an overnight app needs.

Thermal-aware scheduling

The classifier runs in a DispatchQueue whose qualityOfService degrades when the device reports thermal state .serious or worse. The fallback is to halve the window rate and widen the smoothing window, preserving event-level counts at the cost of temporal precision. The alternative — pushing through and getting throttled — corrupts the night with zeros that look like silence.

The user-facing payoff

Handled correctly, the morning summary reads like a careful witness instead of a confident liar:

It shows the gaps.
It flags the thermal-throttled regions.
It tells you which events crossed the confidence threshold and which skimmed it.

That honesty is what earns the place on the nightstand. SleepTrace is architected entirely around treating these constraints as product requirements, not bugs to ship through.

Why we don't upload your bedroom audio (and never will)

SleepTrace — Mon, 10 Aug 2026 00:38:25 +0000

Why we don't upload your bedroom audio (and never will)

The short version: because the moment raw audio leaves your phone, "privacy" becomes a word you can no longer use in good faith. The longer version is about engineering trade-offs that turn into user trust.

Every major sleep-tracker pitch deck eventually slides over a "smart insights" feature that requires server-side processing. The implication is always that the raw audio — eight hours of you, your partner, your dog, your conversations — has to travel somewhere to get smarter. At SleepTrace we made the opposite trade: we made the insights run entirely on-device, and we never accept a feature suggestion that requires uploading raw audio.

The legal and reputational surface of raw audio

Raw audio is not metadata. It is a room recording. Eight hours of bedroom audio contains enough personal data to reconstruct a surprisingly detailed picture: who lives there, the schedule of their partner, whether someone is sick (from cough and congestion), whether children are present (from voices), and — in a not-insignible number of cases — the actual content of private conversations at night.

That is not hyperbole. It is a discovery obligation in a divorce deposition. It is a subpoena target in a custody case. It is a breach waiting to happen. One database exposure, and you are the company that kept everyone's bedroom recordings.

What users actually trade their privacy for

They trade it for convenience or accuracy, and they almost always overestimate both. The accuracy gap between on-device classification and cloud classification, for sleep audio, is noise today — the discriminative features (spectral tilt, zero-crossing, harmonic structure) are cheap to compute and run in real time on modern phones. The convenience is already maximal: the phone is on the nightstand. There is no compelling reason to ship the audio.

The engineering discipline that protects users

We enforce a single rule in code review: any path that touches the network with raw audio payloads is a build-breaking bug. Not a flag. Not a config you can flip. A compile error. This catches the "just add server-side re-scoring" feature request before it ships.

The on-device pipeline is designed around that rule. Features are extracted and the raw PCM ring buffer is overwritten every morning. The only things that leave the device, if you opt into improvement analytics, are aggregate event counts bucketed by hour and confidence level — data that cannot be traced back through an acoustic fingerprint.

The trust dividend

Users notice. Retention on privacy-forward sleep apps tracks the explicit privacy promise: the headline is "audio never leaves your phone," and users quote it back in reviews. Privacy is not a cost center here. It is the feature that distinguishes a product that earns trust from one that rents access to it.

The full on-device acoustic pipeline is documented at the SleepTrace engineering blog.

Building the on-device ML pipeline that powers phone-based sleep analysis

SleepTrace — Mon, 10 Aug 2026 00:38:19 +0000

Building the on-device ML pipeline that powers phone-based sleep analysis

Most sleep-detection demos run a model server-side on uploaded audio. That is the easy path and also the wrong one: it asks users to ship their bedroom audio to a cloud bucket, and it makes the product a privacy liability every time you explain it. The harder and right path is a full CoreML pipeline that takes microphone samples to snore events on-device, in the dark, with no network. Here is how SleepTrace actually wires that together and why each choice matters for overnight battery and user trust.

The pipeline stages, end to end

Capture as a 12.8 kHz mono ring buffer via AVAudioInputNode (pull mode), with a background-task assertion renewed on a 25-second cadence so iOS does not reclaim the budget. Full architectural notes in the field writeup here.
Window into 2-second frames with 50% overlap. Each frame is a fixed cost; batching them in and out of the queue smooths CPU usage.
Feature extraction is a 40-coefficient mel filterbank plus spectral tilt, zero-crossing density, and harmonic-to-noise ratio — the exact discriminators documented on the blog.
Score each frame through a CoreML model exported from a PyTorch training job, quantized to 16-bit for size.
Smooth the frame-level posteriors into event boundaries (snore start/end, breathing pause) in a lightweight temporal pass — no full-night attention model on the phone.
Emit events to a local log; upload, if opted in, is aggregate counts only.

Why on-device is the whole point

Moving the scoring to CoreML is not just a privacy posture. It changes the resource contract:

Latency. A frame is classified in under 2 ms on recent silicon; the OS never has to decide whether to wake a co-provisioned network call.
Battery. There is no radio cost. Radio wakeups dominate overnight phone battery drain, and audio-classification workloads run entirely offline.
Honesty. You cannot accidentally leak the raw audio if the raw audio never reaches a host boundary. The trust model is baked in by construction.

Quantization and the size budget

The full unquantized model is ~80 MB. Quantizing to 16-bit int8 with post-training quantization lands it under 20 MB and changes per-frame accuracy by under 1%. That 20 MB is the ceiling we budget against because iOS does not like resident CoreML models in the multi-hundred-megabyte range on a phone sharing memory with the OS all night.

The one place the model is not the bottleneck

Feature engineering is. The mel filterbank and the spectral-tilt coefficient carry most of the discriminative signal between snoring and speech, and they are trivial to compute. A well-featurized linear separator often matches a much larger neural net here precisely because the feature space is doing the work. Ship the features first; ship the bigger model only if the features alone miss your false-positive budget.

This is the architecture that lets a $600 phone replace a $300 wearable on the nightstand — and it only became feasible once every stage moved on-device.

The audio feature that actually separates snoring from talking in the dark

SleepTrace — Mon, 10 Aug 2026 00:35:26 +0000

The audio feature that actually separates snoring from talking in the dark

Distinguishing a snore from a sentence, or a gasp from a cough, is the core problem in acoustic sleep analysis — and the one that most sleep apps paper over. A naive classifier that fires on "loud breathing in the 200–3000 Hz band" will flag every partner conversation, dog bark, and car horn at 2am as "sleep-disordered breathing." That is why event counts from most apps are unreliable.

This is the signal-processing breakdown of the feature set that SleepTrace actually uses, and why it works on-device without a server.

The time-frequency signature of a real snore

A human snore is not a steady tone. It is an aperiodic burst with a strong low-frequency envelope (roughly 120–450 Hz), modulated by the soft palate, with spectral energy tapering by ~2kHz. A sentence has formant structure — clear peaks at 500, 1500, 2500 Hz corresponding to vowels — and a rhythm tied to phoneme timing.

The discriminator that matters:

Spectral tilt slope. Snoring energy falls off rapidly above 1kHz; speech energy stays flatter. A single tilt coefficient over the 0.5–4kHz window separates most snore/sentence pairs.
Zero-crossing density in the high band. Snoring is voiced and periodic at the glottal rate (~15–30 Hz, with harmonics). High-band zero-crossing density is low for snoring and high for sibilant speech ("s", "sh", "f").
Harmonic structure. Snoring harmonics sit on a single fundamental tied to vocal-fold vibration. Speech has a structured harmonic stack that tracks vowel formants.

Combining the tilt slope + high-band zero-crossing density gives a clean separator that runs in a 40-coefficient mel filterbank and costs ~90% of one CPU core on an iPhone SE for a 2-second window.

The breathing pause signature

A gasp or apnea-related pause is, by definition, the absence of a periodic signal. The trick is distinguishing "quiet because paused" from "quiet because the phone is far away." The feature: a cross-correlation of the current 4-second window against the trailing 30-second median breathing rhythm. A real pause shows a sharp drop in correlation that persists past the window length and is accompanied by a sub-baseline spectral flatness (the body is still trying to breathe, quietly).

Why this works without cloud compute

All of these — spectral tilt, zero-crossing density, harmonic-to-noise ratio — are cheap FFTs on 2-second windows. They map cleanly onto a small neural net (under 2MB) that runs entirely in CoreML on-device. No upload. No server-side feature store keyed off the microphone. No privacy question at all.

The full on-device pipeline and the exact feature coefficients are published on the SleepTrace engineering blog.

For builders: start with the discriminator, not the dataset

Most sleep-audio apps collect thousands of hours of labeled data and then ship a dense transformer that runs hot and uploads raw audio. Start instead with a three-feature linear separator (tilt slope, high-band zero crossings, correlation drop) and a threshold calibrated on-device. It will beat the transformer on battery life, privacy, and honesty — and you will have a product you can ship before the cloud bill arrives.

Stop shipping sleep stage charts you cannot defend

SleepTrace — Mon, 10 Aug 2026 00:33:44 +0000

Stop shipping sleep stage charts you cannot defend

Sleep stage charts are everywhere now. Apple Health, Oura, Whoop, Garmin — every tracker that can guess your breathing gives you a stacked bar of "light," "deep," and "REM" sleep. The charts look scientific. The accuracy does not match the confidence they imply.

Here is the honest problem: without an EEG, sleep stages are a classification task built on proxies. Movement, heart rate, and (if you're lucky) breathing rhythm are fed into a model trained against lab polysomnography. The model outputs a probability distribution, and the app draws it as a fact.

The gap between "probability distribution" and "you were in REM from 01:13 to 01:47" is the entire integrity problem of consumer sleep tracking.

Why stage charts survive anyway

They survive for three reasons, none of which are technical:

They look good. A stacked bar is visual and familiar. Users understand pie charts even when they shouldn't.
They anchor a narrative. "You got 90 minutes of deep sleep" gives a user something to talk about — and to share. Sharing drives retention.
They are internally consistent. Even if wrong, the chart always sums to 100%. That completeness feels authoritative.

None of these are reasons the chart is accurate.

The alternative most apps won't take

Our approach is to surface events instead of stages. The morning view shows: when you snored, when your breathing looked obstructed, how your rhythm shifted relative to your baseline, and — critically — the confidence level for each detection. No stage pie. No 0–100 score.

The full acoustic detection pipeline, including the feature engineering that makes "obstructed breathing" detectable without an EEG, is documented on the blog.

For builders: ship the uncertainty

If you must ship a stage estimate, ship the uncertainty with it. A toggle between "show probability bands" and "show most-likely stage" is enough to make the user understand the chart is a model output, not a measurement. If you won't do that, stop shipping the chart. Sleep is too personal to optimize against a number that is, at best, an educated guess dressed up as data.

Field notes: why background audio on iOS fails silently at 3am

SleepTrace — Mon, 10 Aug 2026 00:33:15 +0000

Field notes: why background audio on iOS fails silently at 3am

If you have ever wondered why your overnight audio app "just stops" after three hours, you have met the iOS background execution budget. The phone does not kill rogue audio apps with an alert. It quietly throttles the process until the audio queue starves and your ring buffer fills with zeros. By morning, your detection looks like a flat line that never happened.

Here is what the documentation does not emphasize and the simulator hides.

The assertion that actually holds it together

AVAudioSession.sharedInstance().setCategory(.record, mode: .measurement, options: [.duckOthers, .interruptSpokenAudioAndSpeechAndReading) is the opening move, not the whole story. You also need a background task assertion that is renewed before it expires. A single beginBackgroundTask request at launch covers ~30 seconds. Overnight, you must renew it inside the expiry handler or the OS reclaims the time budget and your audio queue stalls.

The queue that survives a budget reclaim

Most audio apps use AVAudioEngine with a tap on the input node. That is simple and correct until iOS decides to throttle. The more robust pattern — the one that survives a budget squeeze — is an AVAudioInputNode pull rendering tap combined with a manually-managed ring buffer. Pulling (rather than pushing into a delegate) means you only allocate when you are actually permitted to run. When the OS tightens the budget, the pull simply returns silence until the next allowed window. Your buffer stays valid, and you can detect the "silent gap" as a data-quality flag rather than a crash.

Clock drift kills the timestamps, not the audio

The quiet killer in overnight field work is not a crash. It is clock drift between the audio timestamp (CMTime from the engine) and wall-clock time (Date). Eight hours of 20ms windows means the timestamps diverge by enough that correlating snoring events with "what happened at 01:12" silently fails. The fix is to anchor the audio clock to CACurrentMediaTime at the start of the session and re-anchor after any interruption. We document the exact drift correction used in production, including the code.

The flat-line detector

The most useful production line you can add:

if recentBuffer.maxAmplitude == 0 for more than 180 windows:
    scheduleBufferCheck()   // OS likely throttled the queue
    log("silent stretch", confidence: .low)

It converts a mysterious 3am failure into an observable signal quality problem. The morning report then says "confidence low: possible OS throttling at 02:40–03:12" instead of silently presenting a flat night as "quiet sleep."

The lesson: overnight iOS audio is less about capturing every sample and more about detecting when the capture was denied, then reporting honesty about it.

What the Apple Health sleep score does not tell you

SleepTrace — Mon, 10 Aug 2026 00:33:09 +0000

What the Apple Health "sleep score" does not tell you

Every major health platform — Apple Health, Withings, Fitbit, Whoop — now ships a sleep "score." The number looks scientific. It is not. The score is a proprietary blend of duration, consistency, and a few detected events, weighted by a formula the vendor never explains. The score is the least honest number in your health app, because it collapses a complicated night into a color and a percentage and implies an authority it does not have.

The real cost is not the number itself. It is the way it turns sleep — something every human already understands instinctively — into a task to optimize, a metric to game. A low score in the morning becomes a failure you carry into the day.

Scores optimize for the wrong loop

A well-designed sleep habit loop has three parts:

An event (you slept).
Information you can act on ("you snored more after your 9pm coffee").
A small lever you can pull tomorrow.

A sleep score replaces part 2 with "your score is 64." There is no lever in "64." The score makes people scroll through a dashboard, not change a behavior. It is engagement theater.

What your phone already knows that the score hides

A phone-based tracker that listens at night knows things the score never surfaces:

Whether you turned in later than intended (the timestamp of the last detected sound).
Whether you had a snoring cluster around 01:00 — and whether that matches your alcohol log from 22:00.
Whether your breathing was restless even if your movement was low (quiet tossing).

Those are actionable. "Score: 64" is not.

The alternative: event-based feedback

SleepTrace surfaces the night as a list of detected events with confidence ranges, not a number. The default morning view answers three questions:

Did I snore, and how did it change from my baseline?
Did my breathing look obstructed anywhere?
What is one lever I can pull tonight?

The full technical explanation of the acoustic event detection is available on the blog.

For builders: don't ship a score unless you can defend it

If you are going to assign a number, you must be able to answer: (a) what it is derived from, (b) how accurate it is, and (c) what the user does with it. Most apps cannot answer (c). Until they can, they should stop pretending sleep is a fraction to be optimized.

How to process 8 hours of audio on an iPhone without draining the battery

SleepTrace — Mon, 10 Aug 2026 00:32:15 +0000

How to process 8 hours of audio on an iPhone without draining the battery

An iPhone on a nightstand recording all night sounds impossible from a battery standpoint. A naive AVAudioEngine setup recording 48 kHz stereo for eight hours would torch the battery and the CPU. Yet SleepTrace does exactly this routinely and consistently comes back above 20% battery. The trick is not a clever algorithm — it is a ruthless pipeline architecture.

Here is the field-tested stack that actually runs overnight on device.

Rule 1: never record at full fidelity all night

You do not need 48 kHz to detect a snore. The discriminative information for breathing, snoring, and grinding lives comfortably below 16 kHz. The pipeline:

Input at hardware native (AVAudioSession shared model, no re-render), but immediately downmix to mono.
Resample to 12.8 kHz in a fixed-size ring buffer. This preserves enough to detect snoring (roughly 200–1800 Hz with harmonics) and cuts the per-sample cost dramatically.
Discard the raw PCM immediately after the FFT/window is emitted. Keep only the feature vector in memory.

Rule 2: batch, do not stream continuously

Continuous audio capture with a real-time callback keeps the CPU warm all night. Instead:

Capture in 2-second windows, 50% overlap.
Run each window through a lightweight feature extractor (spectral flux + zero-crossing + band energy).
Sleep the process between windows using a background task assertion.

This yields a bursty CPU profile: ~250ms of work every 2 seconds, then sleep. Battery impact is negligible.

Rule 3: do the ML classification in bursts

The model itself is small (sub-10MB CoreML), but running it every window still costs. The actual architecture:

Feature vectors are written to a ring buffer.
Every fifth window, the ring is evaluated as a sequence with a temporal smoothing pass.
Results are written to a compact log: timestamps + classification + confidence.

This is where the snore/apnea detection detail lives — the acoustic feature engineering is straightforward; the trick is not running it continuously.

Rule 4: guard the background task correctly

// request a background task that expires gracefully
let task = UIApplication.shared.beginBackgroundTask(withName: "audio-processing") {
    // flush buffer, end cleanly
    processor.flush()
}

Without this, iOS suspends the process within ~30 seconds of the screen locking. With it, the pipeline runs undisturbed for the full night.

Rule 5: verify, then forget the raw audio

Only the classification log (a few hundred kilobytes) survives the night. The raw ring buffers are overwritten the next morning. On-device only, always.

The whole pipeline fits under 50MB of RAM and uses roughly 10–14% of a single night's battery on modern iPhones. The constraint that solved it was not faster hardware — it was treating raw audio as ephemeral by design.

Why "sleep stage detection" is the wrong metric for a phone app

SleepTrace — Mon, 10 Aug 2026 00:32:13 +0000

Why "sleep stage detection" is the wrong metric for a phone app

Sleep apps ship stage charts like they're medical readouts. A pie chart that says "you were 23% deep sleep" feels authoritative, but it is a guess built on movement, breathing rhythm, and time-of-night priors — not an EEG. A phone on the nightstand does not have access to the brain waves that actually define N1, N2, N3, and REM.

That does not make phone-based sleep tracking useless. It makes it useful for the things that are actually measurable and actually matter: when you snored, how often you gasped, whether your breathing paused, and how consistent your rhythm was night to night. Those are acoustic events, not inferred brain states.

The mistake is presenting proxies as measurements. The fix is presenting measurements as proxies.

What a phone can actually hear

The accelerometer on a phone on the nightstand gives you movement: did the phone shake, did the table vibrate. That is coarse. The microphone gives you a far richer signal. You can detect:

Snoring intensity and duration per sleep cycle.
Breathing pauses that correlate with apnea events.
Positional snoring patterns (back vs. side).
Environmental noise that fragments sleep.

None of that maps to "Stage 2 sleep," but a user who learns "you snored for 18 minutes in the 01:00 cycle and gasped twice" has something actionable. A user who learns "deep sleep dropped 3%" does not, because deep sleep on a phone is a probabilistic model output dressed as fact.

The right metric stack

Events, not stages. Lead with concrete detected events: snore episodes, breathing pauses, position changes.
Consistency, not snapshots. "Three nights in a row over your baseline" beats "your score is 71/100."
Behavioral levers. Tie events to inputs: "on nights with alcohol after 8pm, snoring doubled."
Confidence flags. Tell the user when the signal was weak (phone too far, noisy environment) rather than hiding uncertainty behind a number.

We built exactly this in SleepTrace: the iPhone on the nightstand runs an on-device audio pipeline that surfaces events and trends, not a stage pie chart you can't act on. The full technical write-up of the acoustic detection is on the blog.

For builders: stop optimizing for the chart

If you are deciding what to ship, ask not "does our model predict sleep stage" but "does the user change behavior after seeing this number." The latter is honest. The former usually is not.