Detecting a Baby Crying or a Household Sound Event at Home

A household sound detector that is 99% specific sounds excellent and is unusable. The reason is arithmetic, not model quality, and it is worth doing once in full because it decides the entire architecture of the product.

A day is 86,400 decisions

Sound event detection runs on windows. A typical configuration takes a one-second analysis window and advances it one second at a time, so a device listening continuously makes one decision per second: 86,400 per day, per microphone. Halve the hop to get better time resolution and it is 172,800.

Compare that with how the model was evaluated. A benchmark set is usually a few thousand clips, balanced or near-balanced across classes, and reported as accuracy or macro-F1. Neither the count nor the balance resembles a day in a house, and the gap between those two situations is where the product fails.

The false-alarm arithmetic

Fix the inputs explicitly. Suppose a baby cries for a total of 12 minutes across the day — 720 windows out of 86,400, a prevalence of 0.83%. Round that to 432 positive windows if you prefer the more typical 7 minutes; the shape of the answer does not change. Take the model at a sensitivity of 95% and a specificity of 99%, both of which would be a good result on a public benchmark.

  total windows per day                  86,400
  crying windows      (0.5% prevalence)     432
  non-crying windows                     85,968

  true positives   = 0.95 * 432          =   410
  false negatives  = 0.05 * 432          =    22
  false positives  = 0.01 * 85,968       =   860
  true negatives   = 0.99 * 85,968       = 85,108

  precision = 410 / (410 + 860) = 0.323

Two out of every three alerts are wrong, from a model with 99% specificity. The device wakes a parent 860 times a day for nothing.

Now ask what specificity would be needed for one false alarm per day, which is roughly the tolerance a person has for a monitor before they switch it off:

  required false-positive rate = 1 / 85,968 = 1.16e-5
  required specificity         = 1 - 1.16e-5 = 99.9988%

That number is not reachable by training a better frame classifier. It is four and a half orders of magnitude of headroom on a quantity that benchmarks report to two decimal places. Any product that works does so because it does not make 86,400 independent decisions.

Why requiring three in a row helps less than it should

The obvious fix is temporal smoothing: only alert when k consecutive windows are positive. If the frame errors were independent with p = 0.01, three in a row would occur with probability 1e-6, giving 0.086 false alarms per day. Problem solved, on paper.

They are not independent, and the reason is structural rather than incidental. Frame errors are caused by things in the room, and things in the room persist. A running tap, a cat, a squeaking hinge, a television, a kettle approaching the boil — each of these produces a sound that is genuinely confusable for many seconds at a stretch. The model is not making 86,400 draws from a coin; it is making a few hundred decisions about a few hundred acoustic situations, some of which it gets wrong for their entire duration.

So k-of-n smoothing removes isolated single-frame errors, which are the cheap ones, and leaves the correlated ones, which are the expensive ones. The realistic gain is often closer to a factor of five than a factor of ten thousand. It also costs recall in a way that shows up on exactly the events you care about: a single sharp cry that lasts two seconds is now below threshold.

Hysteresis is a better version of the same idea — a higher threshold to enter the alerting state and a lower one to leave it — because it stops an event flickering in and out at the boundary without imposing a hard minimum duration on onset. It is still a post-processor, and it still does not touch the correlated-error problem.

Score events, not frames

The real change is in what you count. Merge consecutive positive windows, allowing a small gap, into a single detected event, and compare events against annotated reference events rather than frames against frames. This is the standard practice in the DCASE sound event detection tasks, and the reason is exactly the one above.

Under event-level counting, a 40-minute crying episode is one event rather than 2,400 correct frames, so it cannot inflate accuracy. And a tap running for ten minutes is one false event rather than 600, so the headline false-alarm count stops being dominated by event duration. The numbers get smaller and they start meaning something a user would recognise: a false alarm is a time you were interrupted for no reason.

Two details make event scoring honest. A collar or tolerance must be defined — how far an onset may be from the reference and still count — because exact boundary agreement is not achievable and not meaningful. And the operating point must be chosen and reported, not implied: a single F-score at an unstated threshold hides the whole trade-off, which is why threshold-independent measures over the full operating curve are preferred in the DCASE evaluations. The same distinction between a balanced test set and a deployed distribution shows up again in applause and laughter detection, where the damage comes from a different direction: the class that dominates deployment was never in the test set at all.

What this means for the device

• Run the model on the device. Not primarily for cost, though the per-stream arithmetic is stark. Continuous audio from inside a home is about as sensitive as consumer data gets, and a design that never transmits raw audio is the only one that can honestly say so.
• Gate before you classify. Most seconds in a house are near-silent. A cheap energy or spectral-flux gate that passes only windows above a floor removes the great majority of the workload before the classifier runs, and it removes false positives too, because silence cannot be misclassified if it never reaches the model.
• Adapt to the room, not to the world. A detector that can be corrected — the user marks an alert as wrong and that recording’s embedding joins a per-home negative set — closes the gap on the correlated errors that smoothing cannot. One home has a handful of persistent confusers, and they are stable for months.
• Report false alarms per day, in the specification. Not accuracy, not F1. It is the number the user experiences, it is derivable from the arithmetic above, and quoting it forces the prevalence assumption into the open where it can be argued with.