Run BirdNET-Analyzer on a Raspberry Pi 4 Model B, feed it a USB microphone through ALSA, and write detections to a SATA SSD over USB 3.0 instead of a microSD card. That is the entire build: one board, one mic, one durable store, and a systemd unit that keeps the analyzer alive across reboots. At the catalog prices in the bill of materials below, the parts land between roughly $230 and $360 depending on which microphone you pick.
Who this build is for
This is a build for backyard naturalists, homelab tinkerers, and anyone who wants an always-on acoustic sensor pointed at their own patch of sky. It is not a research instrument and it does not pretend to be one. What it does well is run unattended for months, tag the species it hears with a confidence score, and give you a searchable log you can scroll through on a winter evening to find out that something unexpected passed through in April.
The reason it works on hardware this cheap is that acoustic classification is a small model on a small input. BirdNET-Analyzer slices incoming audio into three-second chunks and runs each one through a TensorFlow Lite convolutional network. That is a tiny amount of arithmetic compared with anything image- or language-shaped, and a four-core ARM CPU chews through it without breaking a sweat. There is no GPU in this build and none is needed.
What separates a logger that survives a year from one that dies in month four is not the compute. It is the write path. A continuously running detector writes clips, spectrogram caches, and a database, forever, to whatever storage you gave it. Point that at a consumer microSD card and you get a silent, unrecoverable failure at an unpredictable date. Point it at a Kingston 960GB A400 SATA SSD behind a USB 3.0 bridge and you get published endurance figures, SMART health reporting, and a warning before anything goes wrong.
The other thing that separates good logs from noisy ones is microphone placement, which costs nothing and is the single highest-leverage decision in the whole project. This guide covers all three: board choice, capture chain, and storage, in that order of how often people get them wrong.
Key takeaways
- The Pi 4 Model B is not the bottleneck for a single microphone. Per the Raspberry Pi 4 Model B specifications, it pairs a quad-core Cortex-A72 at 1.5 GHz with two USB 3.0 ports — enough for real-time analysis of one stream plus a fast storage bus.
- Skip the microSD card for the recording store. The SD Association's Application Performance Class spec defines A2 in terms of IOPS and sustained sequential write, not write endurance — there is no published TBW rating to plan against.
- Codec choice dominates storage capacity by an order of magnitude. Uncompressed 48 kHz mono is roughly 8.3 GB/day; 32 kbps Opus is roughly 0.35 GB/day.
- Power is a non-issue on grid, and a real constraint off it. Per Tom's Hardware's Raspberry Pi 4 review, the board measured about 2.7 W idle and about 6.4 W under full load.
- A Pi 5 is faster but does not fix a bad noise floor. If you live under a flight path, no board upgrade rescues the recordings.
Step 0 — decide what you are actually logging
Do this before you buy anything, because it changes both the microphone and the storage budget.
Event-triggered logging keeps a rolling buffer, runs the classifier continuously, and only writes a clip to disk when a detection crosses your confidence threshold. This is what most people actually want. Storage demand is proportional to how much bird activity you get, not to how many hours are in a day, which in practice means a busy dawn chorus in May and near-silence in January.
Continuous archival writes every second of audio to disk regardless of detections, and runs the classifier over the archive. You want this if you intend to re-analyse the same recordings later with a newer model, or if you are building a dataset rather than a species list. It costs an order of magnitude more storage and it changes the SSD from a nice-to-have into a hard requirement.
Hybrid — continuous at a low bitrate plus full-quality clips around detections — is the configuration most long-running deployments converge on. You keep the ability to re-analyse without paying uncompressed prices for it.
Pick one now. If you are unsure, start hybrid: it is the only choice you cannot retrofit, because you cannot recover audio you never wrote.
What you'll need: the full bill of materials
| Part | Suggested SKU | Catalog price | Why this one |
|---|---|---|---|
| Board | Raspberry Pi 4 Model B (4 GB) | $123.79 | Two USB 3.0 ports, four A72 cores, mature ALSA support |
| Microphone | Logitech Creators Blue Yeti USB Mic | $104.00 | Large-diaphragm condenser, clean capture, class-compliant USB audio |
| Budget mic alternative | NexiGo N950P (Gen 2) webcam | $99.99 | Built-in mic array plus a camera if you want visual confirmation |
| Recording store | Kingston 960GB A400 SATA3 2.5" SSD | $129.99 | 300 TBW rated, SMART reporting, cheap per gigabyte |
| Larger store | Crucial BX500 1TB 3D NAND SATA SSD | $171.00 | 360 TBW rated, room for continuous archival |
| Also needed | USB 3.0-to-SATA bridge, 5 V/3 A USB-C PSU, passive case, foam windscreen | — | The PSU spec is from the official Pi 4 specifications |
Prices are the SpecPicks catalog values as of August 2026 and may vary — check the current price before you buy. The endurance figures come from the Kingston A400 product page and the Crucial BX500 product page.
Two things people forget. First, a passive case, not a fan case — a fan sitting 30 cm from your microphone is a broadband noise source you will be fighting in software forever. Second, a real 5 V/3 A supply. Undervolting a Pi 4 with a USB 3.0 SSD hanging off it produces exactly the kind of intermittent, non-reproducible corruption that costs a weekend to diagnose.
Which Pi do you actually need? Pi 4 vs Pi 5 vs Zero 2 W
| Board | RAM options | CPU | Fast USB | Idle power | Verdict for this build |
|---|---|---|---|---|---|
| Pi 4 Model B | 1/2/4/8 GB LPDDR4-3200 | 4× Cortex-A72 @ 1.5 GHz | 2× USB 3.0 | ~2.7 W measured | The sweet spot — enough headroom, cheap, passively coolable |
| Pi 5 | 4/8/16 GB | 4× Cortex-A76 | 2× USB 3.0 + PCIe | Higher than Pi 4 | Buy it for multi-mic arrays, not for one stream |
| Pi Zero 2 W | 512 MB | 4× Cortex-A53 | USB 2.0 OTG only | Lowest | Viable only for low-bitrate, event-triggered capture |
The Pi 4 specifications are from Raspberry Pi's own product page; the idle figure is Tom's Hardware's measurement. On relative performance, Phoronix's Raspberry Pi 5 benchmark suite puts the Pi 5 substantially ahead of the Pi 4 across a broad mix of workloads — a genuine generational jump, and the right choice if you are running three or four capture devices off one box.
For a single microphone, that headroom buys you nothing you can hear. The Pi 4's constraint is not arithmetic, it is the USB controller, and both boards give you the same two USB 3.0 ports. Spend the price difference on a better microphone or a bigger SSD, both of which change the output.
The Zero 2 W is the interesting edge case. It has four cores, so it can run the classifier, but its only fast peripheral bus is a single USB 2.0 OTG port shared with everything. Run a mic and an SSD off a hub on that port and they will contend. It works for a low-bitrate event-triggered node writing to a small card and syncing off-box — a mesh of cheap remote sensors — but not as your main logger.
Which microphone? Condenser vs lavalier vs webcam array
The Blue Yeti is the reference capture device here for three unglamorous reasons: it is class-compliant USB audio so Linux needs no driver, it has a large diaphragm with usable response across the range where most vocalisations sit, and it has selectable polar patterns so you can switch to cardioid and aim away from a road.
It is also a studio microphone, and studio microphones do not belong outdoors. It must live under a soffit, in a vented enclosure, or on a covered porch, with a foam windscreen. Wind noise is not a minor annoyance in this application — it is a low-frequency wall that raises the noise floor across the whole recording and produces false detections.
The NexiGo N950P is the pragmatic alternative. Its mic array is not as clean as a large-diaphragm condenser, but it is a single sealed unit rather than a delicate desk device, and it gives you a camera alongside the audio. Visual confirmation of an ambiguous detection is genuinely useful when you are calibrating confidence thresholds.
A cheap USB lavalier in a weatherproof housing is the third option, and it is the right one when the mic will be genuinely exposed. You accept a worse noise floor in exchange for a device you do not mind replacing annually. Whatever you choose: never mount a USB microphone where rain can track down the cable into the connector. That is the most common physical failure in these builds and it takes the Pi's USB controller with it often enough to matter.
Why microSD cards fail on this build, and what to use instead
The instinct is to reach for a fast A2 microSD card. The problem is that A2 does not mean what people assume. Per the SD Association's Application Performance Class definition, A2 specifies minimum random read and write IOPS and a minimum sustained sequential write rate. It says nothing about how many terabytes the card will accept before it wears out, and consumer cards generally publish no TBW figure at all.
Contrast that with SATA SSDs, which do. The Kingston A400 at 960 GB is rated for 300 TBW, and the Crucial BX500 at 1 TB is rated for 360 TBW, both per their manufacturers' product pages. Do the arithmetic against a worst-case workload — continuous uncompressed capture at roughly 8.3 GB/day, which is about 3.0 TB/year — and either drive's rated endurance sits far beyond any realistic deployment life.
That is the honest version of this argument, and it is not "your SSD will last longer before wearing out." Neither device is likely to hit a write ceiling. The reason to use an SSD is the failure mode. An SSD reports SMART attributes, so you can poll wear-levelling count and reallocated sectors and get months of warning. A microSD card degrades silently and then hands you a corrupted filesystem with no notice, usually discovered when you go looking for a recording that no longer exists.
Keep the OS on a microSD card if you like — it is mostly read traffic and trivially re-imaged. Put the recording store, the database, and the spectrogram cache on the SSD.
What the Pi 4 has to hit to stay real-time
BirdNET-Analyzer's processing model gives you a hard, checkable budget rather than a vague "is it fast enough" question. The analyzer works on three-second chunks; if you configure overlap, consecutive chunks share audio and the effective interval between analyses shrinks proportionally.
| Configuration | New audio per analysis | Wall-clock budget per chunk | What blowing the budget looks like |
|---|---|---|---|
| 3 s chunks, no overlap | 3.0 s | 3.0 s | Backlog grows, detections lag behind live audio |
| 3 s chunks, 50% overlap | 1.5 s | 1.5 s | Same, twice as fast to accumulate |
| 3 s chunks, 2 mics, no overlap | 3.0 s each | 1.5 s each | One core saturated, queue depth climbs |
Budgets are derived arithmetic from the chunk and overlap settings, not measurements. The point is the diagnostic: instrument your analyzer's per-chunk wall clock, compare it against the budget in this table, and you know immediately whether to reduce overlap, drop a capture device, or move to a faster board. The BirdNET-Analyzer repository documents the TensorFlow Lite model path that makes Pi-class hardware a supported target in the first place.
If you are over budget on a Pi 4 with one microphone, the cause is almost never the CPU. Check for a thermally throttled board in a sealed case, an SSD sharing a saturated USB controller with the mic, or a resampling step you did not intend — capturing at 44.1 kHz and resampling to the model's expected rate on every chunk is a surprisingly expensive mistake.
Storage math: WAV vs FLAC vs Opus
Uncompressed 16-bit mono at 48 kHz is 96,000 bytes per second. Everything below follows from that, from typical FLAC ratios on speech-like material, and from the fact that Opus is designed to operate across a very wide bitrate range — including bitrates far below what lossy music codecs target.
| Format | Bitrate | Per day | Days on 960 GB | Days on 1 TB |
|---|---|---|---|---|
| WAV 48 kHz mono 16-bit | 768 kbps | 8.29 GB | ~104 | ~109 |
| FLAC (≈50% of source) | ~384 kbps | ~4.15 GB | ~208 | ~217 |
| Opus 32 kbps | 32 kbps | 0.35 GB | ~2,470 | ~2,600 |
Capacities assume filling to 90%, which you should — a nearly full SSD writes slower and gives the controller no room to work.
The practical read: continuous uncompressed archival gives you about a season on a 960 GB drive, which is fine if you rotate media deliberately and terrible if you were expecting to leave it alone. FLAC doubles that for free with no quality loss and should be the default for anything you intend to re-analyse. Opus at 32 kbps turns the storage question into a non-question — years on a single drive — at the cost of throwing away detail a future model might have wanted.
The hybrid answer: Opus for the continuous archive, FLAC for clips around detections. You get a multi-year rolling record plus lossless audio for everything the classifier actually flagged.
Power and always-on cost
Tom's Hardware measured the Pi 4 at about 2.7 W idle and about 6.4 W under full load. Add a USB microphone and a bus-powered SSD and a logger running a continuous classifier realistically averages somewhere in the mid single-digit watts — measure your own with an inline USB power meter rather than trusting an estimate, because the mic and the bridge chip vary a lot.
Working from a 5 W average: 5 W × 8,760 hours is 43.8 kWh per year. At an assumed residential rate of $0.16/kWh that is about $7 a year. At a 7 W average it is 61.3 kWh and about $10. Grid power is not a consideration for this build.
Off-grid is a different calculation entirely. A 5 W continuous draw is 120 Wh per day, every day, including December. Sizing a panel for summer output is the classic mistake — winter irradiance in temperate latitudes can be a fraction of the summer figure, so a panel rated at several times the average draw plus three days of battery reserve is the starting point, not the safety margin. Power over Ethernet is the far easier answer if you can run a cable: one wire carries both power and network, and it eliminates the USB-C connector as a failure point.
Software walkthrough
Pick the right ALSA device. arecord -l lists capture devices; note the card and device numbers and address the mic explicitly as hw:CARD,DEV rather than relying on default, which will silently move when you plug in anything else.
Set the capture gain before anything else. Use alsamixer -c <card>, select the capture control with F4, and set the level so that loud nearby vocalisations peak below clipping with real headroom left. This is the step people skip, and skipping it poisons everything downstream.
Verify with a real recording. arecord -D hw:1,0 -f S16_LE -r 48000 -c 1 -d 30 test.wav, then look at the waveform. If it is a flat line or a solid block, the gain is wrong, not the model.
Run the analyzer under systemd. A unit with Restart=always and RestartSec=10 covers the ordinary crash. Add After=network-online.target if you sync detections off-box, and write the detection database to the SSD mount, not to the OS card.
Mount the SSD properly. Use a UUID in /etc/fstab, not /dev/sda1, which will move the first time you attach another USB device. Add noatime — there is no reason to write an access timestamp for every clip you read.
Get detections into something queryable. SQLite on the SSD is enough for a single node. Store the timestamp, species label, confidence score, and clip path, and index on timestamp and species. Confidence is the column you will spend the most time tuning against.
Common mistakes
- Leaving capture gain at its default. By a wide margin the most common failure. The model sees a signal too quiet to classify or clipped into distortion, and you conclude the model is bad.
- Sharing one USB controller between mic and SSD. On the Pi 4, put the SSD on a USB 3.0 port and the microphone on a USB 2.0 port. Audio capture is latency-sensitive and storage writes are bursty; contention shows up as dropouts, not as an error message.
- Tuning confidence thresholds in the wrong season. A threshold calibrated in a quiet January produces a flood of false positives in a loud May. Set thresholds against your noisiest conditions.
- A fan in the same enclosure as the microphone. Broadband noise, permanently, at close range. Use a passive case.
- Trusting the species label without listening. Treat output as a ranked candidate list to review by ear, not as ground truth. This matters most for the rare detections — which are exactly the ones you will be tempted to believe.
When this build is right, and when it isn't
It is right when you have a reasonably quiet location, a covered spot to mount a microphone, and an interest in what is happening over months rather than minutes. Under those conditions a Pi 4, a decent USB mic, and an SSD produce a genuinely useful long-run record for the cost of a mid-range graphics card.
It is wrong beside a busy road, a rail line, or under a flight path. A high ambient noise floor swamps quiet vocalisations, and no amount of model tuning recovers a signal that was never captured. A directional mic aimed away from the noise source helps at the margin; it does not solve the problem. Critically, a Pi 5 or an accelerator does not solve it either — those make classification faster, and your problem is that the audio going in is bad. Compute never fixes capture.
It is also wrong if you need species-level certainty for research or regulatory use. This is a screening tool that produces candidates for human review. Treated that way it is excellent; treated as an authoritative census it will embarrass you.
Bottom line
Buy a Raspberry Pi 4 Model B, a Blue Yeti you can mount under cover, and a Kingston A400 960GB SSD on a USB 3.0 bridge — or the Crucial BX500 1TB if you plan to archive continuously. Set the ALSA capture gain before you touch a threshold, run Opus for the rolling archive and FLAC for detection clips, and keep the OS on a card while everything that gets written lives on the SSD. Spend your remaining attention on where the microphone goes, because that decision outweighs every component choice in this article.
Related guides
- Best Storage for a Raspberry Pi 4 Home Server
- Best SSD for Raspberry Pi Boot in 2026
- Best Raspberry Pi for Local LLMs and Home Lab in 2026
- Raspberry Pi 4 8GB vs a Used Mini PC for a Beginner Homelab
- Best Raspberry Pi Setup for Home Assistant in 2026
Citations and sources
- Raspberry Pi — Raspberry Pi 4 Model B specifications — accessed 21 August 2026
- Tom's Hardware — Raspberry Pi 4 Model B review — accessed 21 August 2026
- Phoronix — Raspberry Pi 5 benchmarks — accessed 21 August 2026
- BirdNET-Analyzer — project repository — accessed 21 August 2026
- Kingston — A400 SATA SSD product page — accessed 21 August 2026
- Crucial — BX500 SATA SSD product page — accessed 21 August 2026
- SD Association — Application Performance Class — accessed 21 August 2026
- Opus Interactive Audio Codec — accessed 21 August 2026
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
