AudioRack: broadcast automation built around the work.

AudioRack Suite is Red Mountain Radio’s modular, digital radio automation and live-assist system. Development began in the early 2000s, informed by direct experience in day-to-day broadcast operations rather than by a generic media-player model.

The system is designed to organize and play the elements that make up a radio hour: music, announcements, imaging, scheduled events, live-assist material, and the transitions between them. Its modular approach lets a station assemble a practical operating environment without treating every studio as though it were identical.

At Mountain Chill, AudioRack is the originating broadcast-audio source. Its continuous program output feeds the studio Red Mountain Radio RSP server, which prepares the audio for resilient delivery to the transmitter via an Internet studio-transmitter link.

The full Audiorack Suite is open source and available at GitHub. Most users benefit from professional installation. Contact us at Red Mountain Radio for details.

AudioRack Live Assist interface showing scheduled audio, playback decks, meters, studio controls, and operator tools.
AudioRack Live Assist. The browser-based operator interface brings together the running schedule, playback decks, audio meters, studio controls, library access, and automation tools in one working view.
AR–01

Automation

Schedules and plays broadcast audio consistently, while supporting the repeatable structure a 24-hour radio service demands. Playlists are built continuously rather than in advance using scheduled elements and algorithmic selections.

AR–02

Live assist

Gives an operator direct control when the station is live, without abandoning the timing and organization of the automation environment.

AR–03

Modular design

Separates functions into practical components so the system can be adapted to the station rather than forcing the station into a rigid workflow.

Red Mountain Radio RSP: designed for the Internet we actually have.

Red Mountain Radio’s custom Resilient Streaming Protocol is a one-way, IP/UDP-based media transport developed for dependable broadcast audio delivery across imperfect Internet links.

Conventional streaming treats lost packets as gone forever. That is a poor bargain for a studio-to-transmitter link: even a brief ISP interruption can become silence or a conspicuous glitch on the air. RSP adds redundancy and time diversity so short losses can be reconstructed downstream.

Red Mountain Radio RSP is intentionally distinct from similarly named commercial streaming products. Here, it refers to Red Mountain Radio’s own broadcast-audio transport system.

Multiple paths. Multiple nodes. One program stream on air.

The architecture separates resilient transport from listener-compatible playback. AudioRack supplies the program; Red Mountain Radio RSP carries it to cluster nodes; each node produces an independent Shoutcast stream. One node is placed at the transmitter, and that is the primary streaming address for the Barix player, translating RSP to standard Shotcast locally.

Stage 1

Originate

AudioRack generates the station’s continuous broadcast program at the studio.

Stage 2

Protect

The studio RSP server adds forward error correction and interleaving before transport.

Stage 3

Distribute

Fiber and cellular paths can reach all three logically connected cluster nodes over the public Internet.

Stage 4

Play

Each node creates a Shoutcast stream. The Barix (or similar) stream player uses whichever stream remains available, the transmitter site node (fed with RSP) is the primary high reliability node. Other nodes can be used for listener Shoutcast streaming.

Blueprint-style block diagram of the Red Mountain Radio RSP cluster-node architecture, showing studio fiber and cellular links, three RSP-to-Shoutcast nodes, transmitter WISP and cellular links, and a Barix stream player selecting among three Shoutcast streams.
Studio-to-transmitter architecture. The cluster nodes exchange logical status and control information over the Internet; Shoutcast audio streams run from each node to the Barix player, not between nodes.
The useful redundancy is layered: two studio Internet paths, two transmitter Internet paths, three geographically separated processing nodes, and three independently selectable Shoutcast streams.
Studio paths
In the setup shown, fiber and cellular paths are used simultaneously to send redundant Red Mountain Radio rsp streams. Both can reach every cluster node.
Cluster nodes
Two nodes are remote on the Internet; the third is located at the transmitter site. The nodes are logically coordinated, but they do not pass Shoutcast audio among themselves.
Transmitter paths
In the setup shown, the transmitter side uses both a wireless ISP connection and cellular service.
Barix playback
The Barix (or similar) stream player can connect to SC3, SC2, or SC1 and move to another available stream if one or more sources fail. Although RSP's redundancy and error correction measures practically guarantee that this fallback is almost never needed.

Forward error correction and interleaving.

Short Internet outages tend to erase adjacent packets in a burst. Forward error correction adds redundant information; interleaving rearranges the transmitted data so one burst is spread across several protected groups after deinterleaving, allowing for correction via FEC.

That distinction matters. FEC can reconstruct only a limited number of losses within a code block. Without interleaving, one outage may wipe out too much of a single block. With interleaving, the same outage becomes a smaller number of losses in many blocks—exactly the sort of damage FEC handles well.

Blueprint-style explanatory diagram comparing forward error correction without interleaving and with interleaving during a short Internet outage that causes a burst of lost bits.
Interleaving does not prevent an outage. It changes the pattern of loss so the error-correction code has a much better chance of rebuilding the original stream.

From playout to exciter, resilience is an end-to-end property.

AudioRack and Red Mountain Radio's RSP protocol solve different parts of the same broadcast problem. AudioRack creates and manages the program. RSP protects that program while it crosses networks the station does not control.

The cluster-node layer then converts the protected transport into standard Shoutcast streams that readily available receiver hardware can play. The result is not dependence on one “perfect” connection. It is a system designed to keep working after ordinary components stop being perfect—which they eventually will, usually five minutes before a very important announcement.

Red Mountain Radio · Ouray, Colorado

Purpose-built broadcast engineering for difficult terrain and real-world networks.

AudioRack and Red Mountain Radio RSP grew from practical station operations: maintaining a continuous, high-quality air signal across mountain geography, remote infrastructure, and Internet connections that occasionally develop personalities.