Before the Alarms

• 

  logo

Inspiration

Cities want faster emergency response to acoustic threats like gunshots and illegal logging, but every existing commercial solution solves this the same way: stream continuous raw audio to a centralized server or human review center. That architecture is a permanent hot mic in public space. It opens the door to unauthorized surveillance, data breaches of private conversations, and the exact kind of regulatory pushback that follows mass surveillance systems, the sort you see in places like China. We wanted to know if faster response and real privacy were actually a tradeoff, or if that was just how everyone happened to build it so far.

What it does

Before the Alarms listens for acoustic threats like gunshots and chainsaws entirely at the edge. Audio is captured into a rolling 2 second RAM buffer. A YAMNet based classifier continuously analyzes that buffer in place. The moment the 2 seconds pass, the raw audio is permanently overwritten, whether or not anything happened. If, and only if, the model detects a genuine threat pattern above a confidence threshold, it sends a small encrypted JSON payload containing a timestamp, device ID, and confidence score. No raw audio ever leaves the device, and no audio is ever stored.

How we built it

We used YAMNet, a model pretrained on AudioSet, as a frozen feature extractor, converting audio clips into 1024 dimensional embeddings rather than training a model on raw audio from scratch. On top of those embeddings, we trained a small classifier head across five classes: gunshot, chainsaw, firework, vehicle, and background. We sourced chainsaw, firework, and vehicle clips from ESC-50, and gunshot clips from a Kaggle dataset covering multiple firearm types. Since our chainsaw and firework classes started out far smaller than our other classes, we built an audio augmentation pipeline that generated pitch shifted, time stretched, noise injected, and volume varied versions of our existing clips to close that gap without needing to source thousands of new recordings. We also built a standalone baseline script that runs YAMNet's own built in AudioSet classes directly, with no custom training at all, as both a sanity check on our data and a fallback path if our custom classifier ran into trouble.

Challenges we ran into

Our two rarest classes, chainsaw and firework, were also our most confusable pair. Early on, a live microphone test misclassified an actual chainsaw as fireworks, which made sense once we looked at the data: both are short, sharp, high energy transients, and we only had 40 firework clips to learn from. We also had a massive class imbalance, with roughly 8500 background clips against a few dozen to a few hundred clips per threat class, which risked the model just learning to predict background every time. On the tooling side, we lost real time to environment issues that had nothing to do with the model, like Windows silently redirecting the python command to a Microsoft Store install prompt, and a git merge that aborted because local untracked audio data collided with incoming files from a teammate.

Accomplishments that we're proud of

Getting a legitimate zero retention architecture working end to end, not just as a diagram but as actual code: a buffer that fills, gets analyzed, and gets purged, with nothing written to disk unless a real threat is detected. We're also proud of validating our approach cheaply before committing to it. Running raw pretrained YAMNet against our own gunshot clips gave us scores above 0.9 with zero training, which told us early that our data and our overall approach were sound before we spent our limited time budget training a custom head on top of it.

What we learned

That the fastest path to a working model isn't always training your own from scratch. Transfer learning on frozen embeddings turned what could have been a multi day training project into something that trains in minutes, and let us spend our actual time on the parts that mattered more for this problem: data quality, class balance, and the false positive behavior between look alike sounds. We also learned how much a privacy preserving architecture can double as a design constraint that makes the system better, not just safer, since being forced to decide in milliseconds whether something is worth keeping pushes you toward a more decisive, more useful model rather than a system that just logs everything and sorts it out later.

What's next for Before the Alarms

Expanding beyond our current five classes to cover more threat and confuser types, and testing on real deployed hardware rather than a simulated daemon, to see how the buffer and purge cycle behaves under actual memory and power constraints. We would also like to explore a distilled, smaller version of the embedding model so the full pipeline can run on genuinely microcontroller class hardware instead of a laptop or Raspberry Pi standing in for one, and to build out the confidence threshold tuning into something cities could actually adjust based on their own tolerance for false positives versus missed detections.

Built With

• audio
• css
• html
• javascript
• kaggle
• ml
• numpy
• python
• tensorflow
• yamnet