SUB/WAVE 1.6: Is a Self-Hosted AI Radio Worth Operating?

SUB/WAVE can turn an existing Navidrome music library into one continuous radio station: an AI DJ chooses tracks, generates links between them, sends speech through a text-to-speech engine, and broadcasts the result through Liquidsoap and Icecast. Every listener hears the same program. That makes it more interesting than another music-player interface—and more demanding to operate responsibly.

OpenSourceChoice verdict: SUB/WAVE 1.6 is worth a private-network pilot for an experienced self-hoster who already runs Navidrome and wants a shared, curated listening experience. It is not yet a low-risk public-radio appliance. Before an internet-facing launch, an operator must resolve music rights, protect the administrative surface, review what leaves the network through model and speech providers, test bandwidth and failure behavior, and validate an open Navidrome ID-migration compatibility issue. For a public or community station, evaluate AzuraCast in parallel; for personal library playback, Navidrome alone remains simpler.

Methodology: This is a researched technical and adoption analysis, not a hands-on review. OpenSourceChoice inspected the v1.6.0 source tag, release and commit history, Docker topology, documentation, license, security policy, public advisories, current issues and pull requests, Navidrome integration evidence, and independent interest signals on August 7, 2026. We did not install SUB/WAVE, stream copyrighted music, benchmark its AI selection, or independently audit every dependency.

Why this matters now

SUB/WAVE v1.6.0 was released on August 6, one day after v1.5.0. Its release notes describe an updated library-exploration strategy intended to escape a repeated-song bubble, a form-validation foundation, and an admin-interface scroll fix. Eight stable tags appeared between July 27 and August 6, while commits continued through August 6. The project is active, but that release velocity also means adopters should expect interfaces and operational behavior to keep moving.

Interest is visible beyond the repository. A Product Hunt launch appeared during the same week, separate Reddit discussions in self-hosting-adjacent communities attracted sustained attention, and Navidrome added SUB/WAVE to its official apps catalogue on August 6. Those are independent discovery signals, not technical proof. GitHub's daily Trending page did not list SUB/WAVE when checked on August 7, and searches across Hacker News, Lobsters, XDA, and broader social sources did not add stronger primary evidence.

The practical reason to examine the project is the format. Most self-hosted music servers optimize for one person choosing one track. SUB/WAVE instead creates a shared program with transitions, requests, hourly archives, optional show planning, and a web player. It asks whether a private music collection can become a small radio operation without adopting a full broadcast stack.

Current state on August 7, 2026

The source tag reviewed resolves to commit c9b4a24d363f44b002722750e6c0b6a7845cae7a. Pinning the tag—or preferably the exact image digest after inspection—matters because the quick-start documentation also offers a moving latest path.

What SUB/WAVE actually does

SUB/WAVE is a radio layer over a music server, not a replacement catalogue and not a Spotify clone. Navidrome remains the source of tracks through the Subsonic/OpenSubsonic API. SUB/WAVE chooses and sequences those tracks, mixes speech and audio, exposes a listener player, and retains operational state.

Navidrome library
       |
       v
SUB/WAVE controller ----> configured LLM
selection, shows,         prompts and DJ copy
requests, state                  |
       |                         v
       +----------------> configured TTS
       |                  local or cloud
       v
Liquidsoap mixer ----> Icecast stream ----> shared listeners
       |
       +----> hourly archives and runtime state

Next.js web/admin <----> controller and public listener API
Caddy edge          ----> TLS and reverse proxy

The default Compose topology includes Caddy, the web application, controller, broadcast engine, Icecast path, an audio analyzer, and a restricted Docker socket proxy. An optional heavy text-to-speech profile adds another service. One Icecast stream is shared: listeners do not get independent queues or personal skips.

The controller can use hosted model providers or a local Ollama endpoint. Text-to-speech choices include local lightweight engines such as Piper and Kokoro, heavier local engines, and cloud providers. If the configured daily model-token cap is exhausted, the documented behavior is to continue the music without generated DJ commentary. That is a sensible degradation mode, but it needs a real failure test.

What it does not do

• It does not supply licensed music. The operator brings the files and remains responsible for the rights attached to the intended audience.
• It does not turn Navidrome into independent on-demand sessions. All listeners hear the same station.
• It does not remove the need to operate Navidrome, storage, backups, TLS, monitoring, and a Docker host.
• It does not make a cloud LLM or TTS provider private merely because the radio application is self-hosted.
• It does not provide the mature scheduling, compliance, relay, and station-management history of a dedicated broadcast platform.
• It does not guarantee compatibility with every future Navidrome database migration simply because both sides speak the Subsonic API.

This boundary determines who should adopt it. SUB/WAVE adds value when the shared-program experience is the objective. If every listener wants personal playback, a standard OpenSubsonic client is the smaller and more reliable system.

Installation and infrastructure reality

The supported path is a Linux Docker Compose host. The CLI quick start writes configuration and starts the stack; the raw-Docker path requires administrative credentials and the public site URL before browser onboarding. Production deployment should place Caddy or another reviewed TLS edge in front of the application, pin images, and store configuration outside an ephemeral container layer.

The default lean analyzer image is documented at roughly 1.1 GB, while the AMD64 heavy analyzer is roughly 1.9 GB. Optional heavy speech images add several gigabytes of PyTorch dependencies. The supplied Compose configuration reserves substantial memory ceilings for analysis and heavy TTS, and GPU variants require a compatible NVIDIA driver and container toolkit. These are ceilings, not measured steady-state requirements; size the pilot from observed CPU, RAM, disk, and latency rather than copying limits into a production capacity plan.

Persistent state lives in bind-mounted directories. It includes settings, runtime state, logs, archives, and secrets needed by the stack. Back up both Navidrome and SUB/WAVE, test a restore on another host, and define archive and log retention. A radio that records hourly output can consume storage quietly even when the music library itself does not grow.

Network cost is easy to underestimate. One shared stream still produces outbound traffic for every connected listener. At bitrate B, average concurrent listeners L, and H broadcast hours, approximate monthly transfer is:

egress bytes = (B bits/second / 8) × L × H × 3,600

At 128 kbps, one always-connected listener is roughly 41 GB over 30 days; ten are roughly 415 GB before web assets, archives, or retries. These are calculated planning values, not SUB/WAVE measurements. Verify the actual encoded bitrate and provider egress policy.

The Navidrome compatibility gate

SUB/WAVE depends on stable track identifiers for selection history, request behavior, and derived state. On August 2, Navidrome merged pull request #5824, which canonicalizes database IDs and notes that most media_file IDs—and therefore related playlist or session references—can change during migration. The change was on Navidrome's development branch and described for an upcoming release when this article was researched; it should not be misreported as part of an already verified stable Navidrome release.

SUB/WAVE issue #1253 tracks the compatibility risk. Draft pull request #1255 proposes preserving derived data before stale records are pruned, but it had no review and was not part of v1.6.0 on August 7.

That makes the upgrade policy straightforward:

1. Pin the current Navidrome and SUB/WAVE versions.
2. Back up the Navidrome database, media metadata, playlists, and SUB/WAVE state.
3. Restore both into an isolated clone.
4. Upgrade Navidrome there and measure lost history, requests, show state, and track associations.
5. Upgrade SUB/WAVE only to a release containing a reviewed compatibility fix.
6. Keep the rollback path until the station has completed a representative broadcast cycle.

A protocol being compatible does not mean every database identity migration is transparent to a dependent application.

Privacy and data flow

Self-hosting keeps the application and music files on infrastructure you control. The AI path can still send contextual data elsewhere.

At the reviewed tag, model prompts can contain current and recent track titles and artists, listener request text, listener count, time, weather, and show context. Generated copy then goes to the selected speech engine. With a hosted LLM and hosted TTS, two providers can receive parts of the station context. A local Ollama plus local TTS configuration reduces that external flow, but increases hardware use, patching work, and latency variability.

Before production, create a provider-by-provider data map:

The project contains defenses that treat listener requests as untrusted input. That is useful, but it is not an authorization boundary. Requests are intentionally public in the listener API and rate-limited; rate limiting does not decide who may influence a program. Moderate requests, limit model tools and outbound domains, and never let generated instructions install code or read secrets.

Custom station skills deserve the same supply-chain review as application plugins. The documentation permits skills with data-fetching code. Inspect every skill, dependency, URL, and permission before installation, especially when sourced from a community repository.

Security and public exposure

The security policy says SUB/WAVE is intended primarily for a private network. Administrative, settings, and debug routes use Basic Authentication, and production refuses to start without configured admin credentials. Listener endpoints such as health, now-playing, state, and request are intentionally public and allow cross-origin access. That design supports an open player, but it also means the reverse proxy and application controls define the internet boundary.

A public pilot should require:

1. TLS with current ciphers and no direct container ports reachable from the internet.
2. Long, unique admin credentials stored outside version control and rotated after staff changes.
3. Network separation between the public edge, controller, Docker socket proxy, Navidrome, and storage.
4. An allowlist for controller egress to the chosen model, speech, weather, RSS, and update endpoints.
5. Request moderation, rate-limit verification, and abuse alerts at the edge—not only application defaults.
6. Image and dependency scanning for every pinned release, including Liquidsoap, Icecast, Caddy, and optional TTS images.
7. Restore drills, secret-rotation drills, and failure tests for LLM, TTS, Navidrome, analyzer, and Icecast outages.
8. Monitoring for stream availability, queue depth, repeated tracks, provider spend, disk growth, authentication failures, and abnormal request text.

The Docker socket proxy narrows access to a read-only, GET-oriented container slice, which is preferable to mounting the unrestricted socket into the controller. It remains part of the host trust surface. Keep it isolated, pin it, and verify that no broader Docker API path is exposed.

Music licensing is the public-launch blocker

The MIT license governs the SUB/WAVE code. It does not grant rights to broadcast the music files.

SUB/WAVE's own documentation warns that public streaming of copyrighted music generally requires appropriate rights and that owning a recording does not by itself authorize a public performance. The U.S. Copyright Office separately explains that a musical composition and its sound recording are distinct copyrighted works, and that digital transmissions can implicate public-performance rights. Other countries have different collecting societies, exceptions, reporting duties, and territorial rules.

This article is not legal advice. The operational conclusion is narrower: do not make the station publicly reachable until the intended territories, audience, interactivity level, repertoire, reporting obligations, and necessary licences have been reviewed with the applicable rights organizations or qualified counsel. A private household network, properly licensed catalogue, Creative Commons material whose exact terms permit the use, or public-domain recordings can produce a different risk profile. Verify each recording and composition; do not infer permission from a playlist label.

For many users, this gate is more consequential than model quality or server size.

License, governance, and lock-in

SUB/WAVE's MIT license is permissive and has not shown a later license-file change in the inspected history. The stack also builds on established open-source components and a documented protocol, so the music library remains in Navidrome rather than a proprietary SUB/WAVE catalogue.

Operational dependence is still real. The 30-day commit sample was heavily concentrated in one identifiable maintainer, releases moved daily, and important compatibility work remained in a draft pull request. That is not enough evidence to declare a numerical bus factor, but it justifies testing whether another contributor can review security-sensitive changes, publish releases, and maintain migrations.

Exit is easier if four assets stay portable:

• original audio files and normalized metadata outside SUB/WAVE;
• Navidrome database and playlists with tested exports;
• station settings, prompts, jingles, and schedules in documented backups;
• Icecast-compatible stream consumers that do not depend on the SUB/WAVE web UI.

The project has low licence lock-in and moderate operational lock-in. Generated station history and AI behavior are valuable only if their state can be restored or transformed after an upgrade.

Alternatives to evaluate in parallel

AzuraCast is the required comparison for a public station because it tests whether mature radio operations matter more than SUB/WAVE's integrated AI personality. Navidrome alone is the control case: if listeners prefer their own queues, the radio layer has failed its product premise.

A measurable 14-day pilot

Run the pilot on a private network with music you are authorized to use and synthetic listener requests.

Days 1–3: establish the baseline

Pin exact versions, inventory containers, record image digests, and restore Navidrome plus SUB/WAVE into a second environment. Disable cloud providers first. Broadcast a fixed library through local selection and measure start time, memory, CPU, disk growth, stream uptime, and repeats.

Days 4–7: evaluate the AI path

Compare local Ollama and local TTS with one approved hosted configuration. Use the same tracks, request set, show format, and evaluation rubric. Record p95 narration latency, failed transitions, repeated songs, metadata sent externally, model tokens, speech cost, and the fraction of time the station continues correctly when either provider is unavailable.

Days 8–10: attack failure assumptions

Stop Navidrome, the LLM, TTS, analyzer, controller, and Icecast one at a time. Fill the archive disk, rotate admin credentials, send adversarial request text, deny external network access, and restart the Docker host mid-program. Confirm that music either continues safely or fails visibly without exposing credentials or corrupting state.

Days 11–14: compare and decide

Run an equivalent schedule in AzuraCast and personal sessions in Navidrome. Interview listeners about the shared format, not just novelty. Estimate monthly hardware, bandwidth, hosted AI, backup, moderation, rights, and operator time.

Approve a continued private deployment only if:

• stream availability exceeds the agreed target during the test window;
• the 24-hour repeat rate and transition-failure rate remain within a defined editorial threshold;
• backup and full restore meet the recovery-time objective;
• provider outages do not stop music or trigger unbounded retries;
• no listener input escapes the moderation and prompt-isolation controls;
• monthly egress, AI, storage, and operator time remain below the budget;
• a cloned Navidrome upgrade preserves the required SUB/WAVE state;
• at least one operator other than the installer can patch, rotate secrets, restore, and roll back the station.

Public approval additionally requires documented music rights for every intended territory, a reviewed exposure model, abuse handling, security monitoring, and a tested compatibility fix for the relevant Navidrome migration.

OpenSourceChoice assessment

• Best for: experienced self-hosters with Navidrome who specifically want one shared, personality-driven station.
• Not for: users seeking personal on-demand playback, a maintenance-free appliance, or a public station without rights and operational staff.
• Why now: v1.6.0, rapid upstream activity, independent community interest, and official Navidrome catalogue recognition make the concept timely enough to evaluate.
• Real cost: Docker operations, AI and speech infrastructure, outbound bandwidth, archives, backups, moderation, licensing work, and release churn.
• Main risk: a public launch combines copyright exposure with an intentionally open listener surface while the young integration is still changing quickly.
• Production gate: verified rights, hardened ingress and egress, provider data mapping, restore and outage tests, version pinning, and Navidrome migration compatibility.
• Parallel alternative: AzuraCast for public radio; Navidrome alone for personal playback.
• Recommendation: run a private, reversible 14-day pilot. Adopt the shared format only if listeners value it after the novelty wears off and the measurable operating burden stays within budget.

Sources

Primary project and integration sources:

• SUB/WAVE repository — Parminder Klair and contributors; architecture, repository activity, issue and pull-request state observed August 7, 2026.
• SUB/WAVE v1.6.0 release — released August 6, 2026; stable version, library-exploration change, validation work, and admin fix reviewed here.
• v1.6.0 source tag — exact source, Docker topology, provider integrations, defaults, and data flows reviewed August 7, 2026.
• SUB/WAVE changelog at v1.6.0 — release sequence and feature history through version 1.6.0.
• SUB/WAVE deployment guide at v1.6.0 — supported Linux Docker deployment, image profiles, TLS, persistence, and production guidance.
• SUB/WAVE security policy at v1.6.0 — private reporting, admin authentication, public listener API, CORS, and deployment threat model.
• SUB/WAVE MIT license at v1.6.0 — software licensing terms reviewed August 7, 2026.
• SUB/WAVE security advisories — GitHub; no published repository advisory observed August 7, 2026.
• Navidrome apps catalogue — Navidrome project; SUB/WAVE listing updated August 6, 2026.
• Navidrome Subsonic API documentation — current integration contract and OpenSubsonic context accessed August 7, 2026.
• Navidrome canonical ID migration pull request — merged August 2, 2026; planned ID migration and compatibility implications.
• SUB/WAVE Navidrome compatibility issue — open integration risk observed August 7, 2026.
• SUB/WAVE draft migration mitigation — draft, unreviewed pull request not included in v1.6.0 when checked August 7, 2026.

Rights and alternative-operation sources:

• Copyright and the Music Marketplace — U.S. Copyright Office; distinction between musical works and sound recordings and overview of relevant rights; accessed August 7, 2026.
• Sections 112 and 114 licensing — U.S. Copyright Office; statutory licensing context for qualifying digital transmissions; accessed August 7, 2026.
• AzuraCast Docker installation — AzuraCast; current supported self-hosted deployment path accessed August 7, 2026.
• AzuraCast changelog — current release and maintenance context accessed August 7, 2026.
• LibreTime documentation — LibreTime; current broadcast-automation scope and deployment documentation accessed August 7, 2026.

Independent discovery signals:

• SUB/WAVE on Product Hunt — August 2026 launch signal; used to establish current interest, not technical quality.
• SUB/WAVE community discussion — July 2026 discussion; independent interest signal only.
• Self-Host Weekly, July 17, 2026 — independent self-hosting discovery signal published before the stable 1.0 release.

Architecture judgments, risk classifications, pilot thresholds, cost implications, and the adoption verdict are OpenSourceChoice editorial analysis. Project descriptions and release claims remain maintainer-published statements unless explicitly identified as independently measured.