AI-powered dog bark detector

4120 manual disturbance text notes

1295 manual disturbance audio recordings of disturbances

We have manually collected 679 sound samples using the exact hardware setup and location that would be later used for detection. Collecting samples took about a month and labeling fragments took about a week of work.

Manually labeled fragments are sliced into Windows that have a fixed length of 0.96s, as required by the sound classification neural network YAMNet. We discard windows that may have not enough information, such as the incomplete ones in the end of fragments — those may just include silence after barks

Audio is mixed to mono, resampled to 16 kHz and passed through YAMNet. Its overlapping analysis windows are approximately 0.96 seconds long with a 0.48-second step, each producing a 1024-dimensional embedding. The custom part is that Barktown then trains a small classifier that combines 128 learned sound patterns and produces a single score for how bark-like the audio is. During training, some signals are randomly hidden to reduce memorisation. Training stops when performance on held-back audio no longer improves. The final cutoff balances detected barks against false alarms, favouring fewer false alarms when undecided.

The current instrument is a RØDE VideoMic NTG connected to a Raspberry Pi. The live stream is captured at 48 kHz and resampled to 16 kHz for YAMNet. A trailing 1.5-second buffer is scored every 0.25 seconds. Current bootstrap defaults require a score of at least 0.92, four accepted hits within a 30-second sliding window and at least 1.5 seconds between counted hits. That minimum separation — called hit refractory in the code — stops overlapping analysis windows from double-counting barks.

A deterministic state machine moves through IDLE → ACTIVE_CANDIDATE → ACTIVE_CONFIRMED → COOLDOWN. A 120-second sub-threshold gap closes the current session in the boot configuration; renewed barking during cooldown reopens it. Audio is encoded in memory, uploaded to MinIO, validated by the ingest service, indexed in SQLite and exposed to the UI with waveform and per-hit metadata.

The live device uses an in-memory ring buffer, avoiding continuous day-long audio storage and unnecessary writes to the Pi’s SD card. In the current bootstrap configuration the buffer holds 700 seconds, confirmed events can extend to 570 seconds, and 1.5 seconds of padding is added at each end before upload. Detector parameters are stored in the API/database and can be updated during runtime.

The runtime is split across four version-controlled repositories: the SvelteKit UI, the Python Raspberry Pi monitor, the Node/SQLite ingest API and the Python training/calibration utilities. Audio objects live in S3-compatible MinIO storage; diary, annotation, detector-parameter and provenance records live in SQLite. The API is the persistent source of truth for live tuning, while checked configuration supplies validated first-boot fallbacks.

Model artifacts are deployed as a TFLite classifier plus adjacent metadata; the runtime verifies the declared filename and SHA-256 before loading a new bundle. The same scoring and hit-gating core is reused for live inference and offline re-analysis, reducing the risk that the review path silently applies different rules.

Operational status includes microphone presence, stream state, sample rate, recent RMS and peak levels, clipping, x-runs, CPU temperature, storage, network reachability and upload counters. The monitor and its status service run separately, so observation of the instrument does not share the detector’s main process.

This is event-triggered sampling. It is efficient and privacy-conscious, but it has an important evidentiary limit: saved clips can confirm what the detector captured, while the absence of a clip does not by itself prove the absence of barking. Training fragments retain their parent recording and time bounds so their provenance can be traced.