← back to projects

lyrebirdaudio-go

A Go port of LyreBirdAudio for static-binary deployments

lang Go license MIT view on GitHub →

Highlights

  • Single static Go binary, drop it on any Linux host
  • Shares the design of the shell-based LyreBirdAudio for feature parity
  • Replaces multi-script installs with a single executable

Background

LyreBirdAudio was originally a bundle of shell scripts, which is the pragmatic choice for a project that mostly wraps udev, arecord, and mediamtx. It’s also the wrong choice for operators who want a single compiled artifact they can drop into a configuration management system without worrying about Bash version drift, missing coreutils, or the difference between BusyBox awk and GNU awk. lyrebirdaudio-go is the Go port that answers that concern.

What it does

Same design as the shell version (stable device naming via generated udev rules, non-invasive capability detection, self-healing recovery loops, health checks) packaged as a single static Linux binary. Cross-compile once, scp it onto the target, and it runs.

Why Go specifically

Go is the right language for this project because the distribution story matters more than peak performance. The workload is almost entirely subprocess orchestration and config generation, with an ffmpeg-driven audio pipeline doing the heavy lifting underneath. What matters is that the orchestrator is one static binary with no runtime dependencies, compiles in seconds, and produces a clean diff against the shell version during review. Go wins that brief comfortably.

The Rust ports in the portfolio exist where Rust’s guarantees buy something real (FFI safety, memory footprint, concurrency correctness). The Go ports exist where the distribution model is the dominant concern. The distinction is deliberate.