Liquidsoap gives dead air a place in the program

Maison de la Radio and Pont Rouelle, Paris, photographed by Edison McCullen on May 17, 2018. Radio France publishes its Liquidsoap streaming configuration; this photograph shows the broadcasting setting. CC BY-SA 4.0.[2][7]

Imagine a presenter disconnecting halfway through a live show. The next sound could be a standby recording, a return to the music playlist, or silence. In Liquidsoap, the open-source language for building media streams, that choice can be expressed in the program's structure. Following the next frame of audio through its sources, fallback rules, and clocks explains how the system keeps a station moving.[1][3]

The architectural starting point is a division of labor. In a conventional internet-radio setup, Liquidsoap assembles and encodes the program; Icecast distributes it to listeners; their players turn the received stream into sound. Adding listeners chiefly increases distribution work. Choosing what those listeners hear belongs upstream.[1] The examples here follow Liquidsoap's 2.4.5 documentation, with Radio France's public deployment serving as a separate operational example.

The output asks for the next frame

A Liquidsoap script builds a network of sources. A source supplies small frames of media, accompanied where appropriate by metadata and track boundaries. A playlist, a live input, and an operator combining other sources can therefore participate in the same system.[3]

At each clock tick, an output asks its source for data. That request travels through the connected operators until it reaches something that can supply the samples. output.icecast might draw from a fallback, which selects a playlist. The script describes relationships that are exercised repeatedly while broadcasting.[3]

Some inputs also need attention while they are off air. The source documentation identifies input.harbor, which accepts incoming live streams, as active: receiving data cannot simply stop because another source is currently selected.[3] That distinction makes a standby feed more than an unused variable. It has a life before the listener hears it.

A filename still has to become sound

Recorded material enters through another abstraction: the request. request.create accepts a URI, but creating the request does not play it. A request-based source such as playlist or single must resolve it and obtain decodable material.[4]

Resolution can involve several steps. A custom protocol might turn a media-library identifier into a URL; the HTTP handler downloads the file; a decoder must then be able to read it. Reaching a local file is insufficient if its contents are unsuitable.[4] A schedule containing an entry and a source being ready to broadcast are different conditions.

Metadata also has a deadline. Liquidsoap's annotate: protocol can supply cue_in and cue_out during request resolution. Those instructions must reach the decoder before playback; attaching them farther downstream cannot retroactively change what the decoder read.[4] This is a useful architectural lesson: information belongs at the stage where it can still affect the work.

Available audio can still be silence

Liquidsoap distinguishes fallible sources from sources expected to remain available. An ordinary playlist is fallible: its files may be invalid or unreachable. By default, an output demands an infallible input. A fallback ending in single("standby.ogg"), with a valid local recording, can provide that continuity. Alternatively, mksafe supplies silence when its input fails.[1]

The word infallible has a deliberately narrow meaning here. It describes the source's availability within the streaming model. It cannot certify the program's usefulness, or keep a powered-off machine broadcasting.

A connected studio can send silent audio indefinitely. Liquidsoap addresses this through a separate operator, blank.strip, which makes an input unavailable after excessive blank audio. A surrounding fallback can then select another source. Its documentation illustrates max_blank=5. together with track_sensitive=false: after five seconds of blank input, an interlude takes over; when sound returns, the live source can resume without waiting for the interlude's track boundary.[5]

That setting expresses an editorial decision. A long pause might be a technical failure, a dramatic reading, or the intended end of a piece. The detector measures an audio condition; the station decides when that condition warrants intervention. Keeping the rule visible makes it possible to discuss and rehearse the interruption before it happens on air.

A crossfade needs access to the future

Source selection answers where audio comes from. Clocks govern how quickly the system consumes it. Each source belongs to one clock; Liquidsoap normally works out the assignments without explicit instructions.[6]

Recorded music can be read ahead. A crossfade needs this freedom because overlapping tracks temporarily requires consuming material faster than the outgoing stream plays it. A live input governed by its own timing cannot necessarily grant the same freedom. The clock documentation shows an SRT input rejected when connected to a crossfade that needs control over its pace.[6]

buffer() can bridge clock domains by queueing media between them. The queue has limits: sufficiently mismatched rates can exhaust it or fill it. Buffering therefore introduces a capacity and timing decision, rather than an unlimited cure for disagreement between devices.[6] For someone assembling a studio feed, the practical question is which component controls the pace and how much waiting the others can tolerate.

What a broadcaster adds around the graph

Radio France's published configuration makes these abstractions concrete. Its README describes multiple SRT feeds carrying the same station audio over different network paths. A Liquidsoap process selects among them to construct radio_prod, which is then encoded into several profiles and delivered through Icecast and HLS.[7]

The configuration also exposes preferred_output, real_output, and is_output_blank. These distinguish the configured or manually chosen preference, what the fallback system actually selected, and whether that selection is producing silence. Monitoring includes input readiness, audio levels, and buffer state.[7] A running process is only the beginning of the evidence that a broadcast is healthy.

Liquidsoap's position inside a larger station system has a long history. Nathan Willis's 2012 LWN report on Airtime described it as the stream generator beneath the radio-management application.[8] That independent account helps explain why a small language can matter beyond the people who write its scripts: scheduling and presentation interfaces can sit above the media machinery.

My reading of this design is that its strength lies in making continuity inspectable. For a small station, that still requires someone who can maintain the script and test failed files, disconnected presenters, silent inputs, and recovery. For a larger operation, Radio France demonstrates the additional value of observing the selected source and its condition.[7] The satisfying moment is not merely hearing the standby recording start. It is being able to explain why it started, what is playing now, and what will bring the live program back.

cronfeed.work