The Core Streaming Chain

At runtime, Spotycast is not a single monolith. It is a pipeline. Each component has a narrow role, which keeps the architecture understandable and easier to troubleshoot.

What spotifyd Does

spotifyd is the upstream playback endpoint used by the stack on the Spotify side. It is responsible for participating in the playback flow and receiving the Spotify audio inside the runtime environment.

• Acts on the Spotify-facing side of the pipeline
• Receives playback from the Spotify control path
• Feeds the local audio environment used by the rest of the chain
• Can be impacted by discovery issues independently of Icecast publishing

What Liquidsoap Does

Liquidsoap is the stream-routing core of the architecture. It reads the audio coming from the local playback path, then applies the publishing logic that turns this audio into one or more outbound streams.

Main responsibilities

• Read the local audio source
• Route audio to one or more output definitions
• Encode, remux, or preserve the stream depending on profile and target format
• Forward the result to Icecast
• Maintain mountpoints while playback is active

What Icecast Does

Icecast is the publishing layer. Its role is not to discover Spotify devices or manage playback logic. Its role is to expose the finished stream through stable HTTP endpoints on the network.

What Icecast provides

• One or more network-accessible mountpoints
• A standard HTTP streaming model understood by many players
• Status visibility for published streams
• A predictable distribution layer decoupled from the Spotify control side

'http://<HOST>:28000
'http://<HOST>:28000/spotify.aac
'http://<HOST>:28000/spotify.mp3
'http://<HOST>:28000/flac

How Players Consume the Stream

Once a mountpoint exists, the player side becomes simple. Roon, LMS, Volumio, and other compatible clients just consume a stream URL. They do not need to participate in the Spotify-side logic of the runtime chain.

Stable Lossy Path vs Advanced Audio Path

Spotycast can be operated with different output profiles depending on the intended use case and the target players. The technical distinction is not about marketing tiers first; it is about how the stream is published and in what format the downstream system consumes it.

Stable lossy path

• Compatibility-first publishing model
• Simple player ingestion through common HTTP stream formats
• Often the easiest path for broad network-player support

Advanced audio path

• More demanding output profile
• Can expose higher-end HTTP stream variants where configured and available
• Useful for systems that care about stricter control over the published stream path

Why This Architecture Is More Resilient

The architecture reduces coupling between the Spotify-facing control layer and the final playback layer. That does not eliminate every possible issue, but it narrows failure domains and makes the system easier to reason about.

• The player only needs an HTTP stream, not deep Spotify integration
• Publishing is handled by Icecast, not by each playback device individually
• Routing and output logic live in one place inside the stream pipeline
• Troubleshooting becomes more modular: discovery, routing, and publishing can be isolated more easily

Ops and Runtime Checks

What to verify first

• Icecast is reachable on the expected port
• At least one mountpoint appears when playback is active
• Liquidsoap is actually publishing to Icecast
• The player can open the published mountpoint URL

tail -n 200 /var/log/spotify-roon-bridge/liquidsoap.stderr.log || true
tail -n 200 /var/log/spotify-roon-bridge/icecast2.stderr.log || true
tail -n 200 /var/log/spotify-roon-bridge/pulseaudio.stderr.log || true