Audio anomaly detection lets you hear problems in motors, pumps, fans and gearboxes before they turn into breakdowns. This use-case guide explains how acoustic monitoring works, which models run comfortably on edge hardware, and how to publish anomaly scores over MQTT so that dashboards and maintenance teams get a clear signal without anyone streaming raw audio.
Why Listen to Machines
Experienced technicians diagnose machines by ear: a whine from a dry bearing, a rhythmic knock from a loose mount, a hiss from a leaking valve. Acoustic monitoring automates that skill and applies it around the clock.
Sound has practical advantages over other sensors:
- Non-contact. A microphone does not need to be mounted on a rotating shaft or wired into a controller, which makes retrofits easy.
- Wide coverage. One microphone can monitor a small group of machines or a whole conveyor section.
- Rich information. Frequencies reveal rotation speeds, friction, cavitation, air leaks and impacts.
- Cheap hardware. MEMS microphones cost little and digital ones connect directly to microcontrollers and single-board computers.
The downside is noise. Factories are loud, background sounds change constantly and neighbouring machines bleed into every recording. A useful system must separate "different from usual" from "the forklift drove by".
How Audio Anomaly Detection Works
Almost all practical systems follow the same pipeline.
1. Capture
Record short clips (typically one to ten seconds) at 16 kHz or higher. Many machine faults show up below 8 kHz, but air leaks and some bearing faults produce ultrasonic or high-frequency content, so match the sample rate and microphone to the fault you care about.
2. Feature Extraction
Raw waveforms are hard to compare. Convert each clip into a log-mel spectrogram: a time-frequency image where frequency bands are spaced the way human hearing perceives pitch, with energy on a logarithmic scale. Simpler alternatives include band energies, spectral centroid and RMS level.
3. Learn Normal
Because failures are rare, models are trained only on normal recordings. The goal is not to recognize a specific fault but to measure how far a new clip is from everything the model has heard during normal operation.
4. Score and Decide
Each clip receives an anomaly score. A threshold, set from the score distribution of held-out normal recordings, decides whether the clip is unusual. Persistence rules (several unusual clips in a row) suppress one-off noises.
Model Options for the Edge
| Approach | How it scores | Hardware | Strengths | Weaknesses |
|---|---|---|---|---|
| Band-energy baseline | Distance from per-band mean and variance | Microcontroller or Pi | Tiny, explainable | Misses subtle pattern changes |
| Gaussian mixture on features | Negative log-likelihood | Raspberry Pi class | Handles multiple operating modes | Needs careful feature choice |
| Isolation Forest on features | Path length | Raspberry Pi class | Multivariate, quick to train | Feature engineering required |
| Convolutional autoencoder | Reconstruction error on spectrograms | Pi with accelerator, Jetson | Learns complex patterns | More data, harder to explain |
| Pretrained embedding plus distance | Distance to normal embeddings | Jetson or GPU edge box | Strong with little training data | Larger model |
A sensible path is to start with the band-energy baseline, prove that sound carries signal for your machine, and then move to an autoencoder if needed. The Isolation Forest for sensor data tutorial shows the feature-based approach in detail, and the same pattern applies to audio features.
A Minimal Edge Listener with MQTT Output
The script below runs on a Raspberry Pi or any Linux machine with a microphone. It records two-second clips, computes log energies in mel-spaced bands, learns a baseline during the first minutes, and then publishes an anomaly score for every clip.
pip install "paho-mqtt>=2.0" numpy sounddevice
# On Raspberry Pi OS you may also need: sudo apt install libportaudio2
import json
import time
import uuid
import numpy as np
import paho.mqtt.client as mqtt
import sounddevice as sd
PREFIX = "connectmq/demo/snd-4be0/plant1/line2/fan3"
RATE, CLIP_S, BANDS = 16_000, 2.0, 32
LEARN_CLIPS = 60 # about two minutes of normal sound
THRESHOLD = 4.0 # mean absolute z across bands
def mel_edges(n_bands, fmin=50, fmax=7_800):
mel = lambda f: 2595 * np.log10(1 + f / 700)
inv = lambda m: 700 * (10 ** (m / 2595) - 1)
return inv(np.linspace(mel(fmin), mel(fmax), n_bands + 1))
EDGES = mel_edges(BANDS)
def band_features(clip):
spec = np.abs(np.fft.rfft(clip * np.hanning(len(clip)))) ** 2
freqs = np.fft.rfftfreq(len(clip), 1 / RATE)
feats = [spec[(freqs >= lo) & (freqs < hi)].sum() for lo, hi in zip(EDGES[:-1], EDGES[1:])]
return np.log10(np.array(feats) + 1e-10)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"listener-{uuid.uuid4().hex[:8]}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
history, mean, std, streak = [], None, None, 0
while True:
clip = sd.rec(int(RATE * CLIP_S), samplerate=RATE, channels=1, dtype="float32")
sd.wait()
feats = band_features(clip[:, 0])
rms_db = float(20 * np.log10(np.sqrt(np.mean(clip ** 2)) + 1e-9))
if len(history) < LEARN_CLIPS:
history.append(feats)
if len(history) == LEARN_CLIPS:
mean = np.mean(history, axis=0)
std = np.std(history, axis=0) + 1e-3
client.publish(f"{PREFIX}/audio/status",
json.dumps({"state": "monitoring", "bands": BANDS}),
qos=1, retain=True)
continue
z = np.abs((feats - mean) / std)
score = float(np.mean(z))
top_band = int(np.argmax(z))
streak = streak + 1 if score > THRESHOLD else 0
msg = {"ts": time.time(), "score": round(score, 2), "threshold": THRESHOLD,
"rmsDb": round(rms_db, 1),
"topBandHz": [round(EDGES[top_band]), round(EDGES[top_band + 1])],
"isAnomaly": streak >= 3, "model": "band-baseline-v1"}
client.publish(f"{PREFIX}/audio/score", json.dumps(msg), qos=0)
The message deliberately carries the frequency band that deviated most. A technician who sees "anomaly, strongest change 2.1 to 2.4 kHz" has a much better starting point than one who sees a bare red light.
Run it in a quiet room, let it learn for two minutes, then play a tone or tap the desk near the microphone and watch the score rise:
mosquitto_sub -h broker.connectmq.com -p 1883 -i snd-watch-4be0 -t "connectmq/demo/snd-4be0/#" -v
Why Publish Scores, Not Audio
Streaming raw audio from every machine is expensive, privacy-sensitive (microphones may capture conversations) and unnecessary. Scoring at the edge and publishing a compact JSON message every few seconds keeps bandwidth tiny and keeps sound on site.
When a clip is flagged, you may still want evidence. A good compromise is to store the flagged clip locally and publish only its metadata, or to upload short snippets on request through a command topic, staying under the broker's message size limit.
Moving from Baseline to Autoencoder
If the band-energy baseline proves that sound carries signal but misses subtler faults, the usual next step is a small convolutional autoencoder trained on log-mel spectrograms of normal clips. Train it on a workstation, convert it to TensorFlow Lite or ONNX, and run it on the edge device in place of the baseline. The MQTT side does not change at all: the listener still publishes a score, a threshold and the model version on the same topic. Dashboards and alert rules keep working, and you can compare the two models by running them side by side for a week, each publishing to its own score topic.
Deployment Checklist
- Mount consistently. Moving the microphone changes the baseline; fix it in place and document its position.
- Record all normal modes. Idle, half load, full load and startup each sound different; learn them all or condition on machine state.
- Use machine state as context. Subscribe to the machine's state topic and skip scoring during changeovers or cleaning.
- Set thresholds from held-out normal data, not from the training clips themselves.
- Require persistence before alerting.
- Protect privacy. Process audio locally and never publish raw clips to shared or public topics.
- Re-learn after maintenance. A new belt or bearing legitimately changes the sound.
From Score to Maintenance Action
Anomaly scores become valuable when they join other signals. A rising acoustic score together with rising vibration and temperature is strong evidence; an acoustic spike alone during a forklift pass is not. That fusion and the step to estimating failure times are covered in predictive maintenance with machine learning, while IoT anomaly detection methods explains where each detector should run. The AI and IoT guide puts acoustic monitoring in the context of the wider edge AI landscape.
Connecting Listeners to the Plant
Each listener is just an MQTT client, so adding one more machine means deploying one more device with its own topic. For experiments, the free public MQTT broker area is fine with synthetic sounds. For real machines, use a private MQTT broker in the cloud with TLS on port 8883 and credentials per listener. ConnectMQ shows each listener in the devices view organized by ISA-95 levels, lets you watch scores in the live topic explorer and can raise threshold alerts on the score field without extra code.
Start Listening with ConnectMQ
Create a ConnectMQ broker on the free Serverless plan at app.connectmq.com, no credit card needed, swap the host and credentials into the listener script and watch your first machine's acoustic score appear in real time.
Frequently Asked Questions
What microphone should I use for audio anomaly detection?
A digital MEMS microphone or a decent USB microphone is enough for most audible faults. For air leaks and early bearing damage, consider microphones and sample rates that capture higher frequencies.
Can audio anomaly detection run on a microcontroller?
Simple band-energy baselines and small TinyML models run on capable microcontrollers such as the ESP32-S3. Autoencoders on full spectrograms usually need a Raspberry Pi with an accelerator or a Jetson-class device.
How do I handle loud background noise?
Place the microphone close to the machine, learn the baseline under realistic background conditions and require several consecutive anomalous clips before alerting. Directional microphones also help.
Is it safe to send audio over MQTT?
Prefer sending scores and metadata instead of audio. If you must send clips, use a private broker with TLS and credentials, never a public test area.
