← All mockups

PACKETCAST ARCHITECTURE

PacketCast is radio playout and automation with a live-assist mode. A headless engine plays the audio and runs the streams, and a studio screen controls it. This page explains how the parts fit together. The working plan is in PLAN.md.

PacketMatrixThe engine. A headless Rust daemon that plays, mixes and routes audio to sound cards and streams. It runs as a core, a studio node or an affiliate.
PacketDeckThe studio screen. A web app (with a desktop wrapper in studios) for on-air control, the log, the library and scheduling. It never plays audio itself.
System

One engine, three roles

The same PacketMatrix program runs everywhere, and config sets its role. The core sits in a rack or the cloud with no screen. Studio nodes and affiliates are the same software on other machines. PacketDeck talks to whichever node it's pointed at.

Music schedulerclocks or imports Traffic systemspot logs, reconciliation Media libraryNAS / S3, local caches PACKETMATRIX · core role Log servicehours, timing, backtimeversioned edits Library + analysisBWF cart chunk, R128auto intro / segue Playout engineplayers · stack · mixerrouter · per-card resamplingencoders · silence detectholds next 30–60 minin memory REST + WebSocket APIstate, meters at 20 Hz, commands Icecast / ShoutcastMP3 · AAC · Opus Network feed outHLS · SRT · Icecast + cues Transmitter feedsound card / AES67 MATRIX · STUDIO NODEpresenter PC, PacketDeck on screenplayers → desk faders on local cardsdesk output → Opus → SRTfader start: MIDI / GPIO PACKETDECKany browser, or Tauri on studio PCson air, log editor, libraryscheduler, voice tracking MATRIX · AFFILIATEone per local stationtakes the network streamcue → local ID / break / newsreports as-run to the hub programme feed + log sync REST + WS via a streaming relay
The core reads logs from the schedulers, plays them and feeds every output. Studio nodes, PacketDeck screens and affiliates all connect to it.
Roles

What each role does

Core

Runs automation around the clock.

  • Plays the log in Auto, with no screen needed
  • Encodes the Icecast streams and the network feed
  • Feeds the transmitter by sound card or AES67
  • Takes over if a studio feed drops

Studio node

Runs live assist on the presenter's PC.

  • Each player goes to its own desk fader
  • The cart wall and hotkeys go to another fader, PFL goes to the cue speaker
  • The desk output comes back in and is sent to the core
  • Keeps playing from its local cache if the network drops

Affiliate

Runs a local station on a network.

  • Takes the network programme from a stream
  • Buffers a few seconds so it can switch cleanly
  • Fills cue windows with local idents, breaks or news
  • Reports what it played for proof of play
Live assist

How the presenter's audio reaches air

STUDIO STUDIO NODEPlayer 1 → card ch 1/2Player 2 → card ch 3/4Player 3 → card ch 5/6Stack → ch 7/8Carts → ch 9/10 MIXING DESKfaders 3–7mics, phones, guestsfader start → MIDI/GPIOprogramme out PGM back in COREsource: studio 1silence detectfalls back to Autofrom the last position desk output · Opus 256k · SRT (resends lost packets) failover Icecast streams Network feed Transmitter
Presenters work the desk as usual, with no delay. The core only switches sources. If the studio feed goes silent, the core carries on in Auto from where the studio was.
  1. The studio node plays the log through local sound cards into the desk, with each player on its own fader, as in BCX.
  2. The desk's programme output comes back into the PC and goes to the core as Opus over SRT, which resends lost packets on poor links.
  3. The core treats the studio as a source. It keeps encoding the streams and feeding the transmitter.
  4. If the studio feed goes silent for longer than a set time (for example 15 seconds), the core takes over the log from the last confirmed position. The presenter sees "core has control" and can take it back.
Sound cards

Several cards at once

Any player can go to any output through a routing matrix, so a studio can give every player its own desk fader. Each sound card runs on its own clock, and two cards slowly drift apart, typically by tens of parts per million. Without correction, the second card glitches every few minutes. PacketMatrix resamples each output slightly to keep every card in step with one master clock. This is the main technical risk, so it's the first thing to prove (Phase 0).

Networks

Getting cue points to local stations

Local stations take the network programme from an intermediate stream (a relay, streaming server or CDN), not directly from the hub. So the cue markers have to survive whatever is in the middle. The hub can send cues in several ways at once, and each affiliate uses whichever its feed supports.

HUB · COREnetwork programmefires cues from the logor an operator STREAMING RELAY / CDNIcecast server, SRT relay,or HLS on a CDNcues must pass through audio cues AFFILIATE · NORTHlocal ID · 4-spot break · live local news AFFILIATE · COASTlocal ID · 3 spots + bed fill AFFILIATE · CITYno news rule → stays on the network
Each affiliate buffers 5–10 seconds of the feed. Cues give advance notice and a break length, so the switch is clean even if the relay adds jitter.
How cues travelThroughTimingDelayGood for
HLS with cues in the playlist
The standard way ads are inserted over a CDN		Any CDN, including CloudflareExact to the segment6–20 sCDN DELIVERY
MPEG-TS over SRT or RIST
Broadcast cue messages unchanged		An SRT relay that passes data throughExact1–2 sLOW DELAY
Icecast with cues in the metadata
Each cue says "out in 4 s, 2:30 long"		Any Icecast or Shoutcast relayOgg/Opus: tens of ms
ICY: about 0.5 s		A few sEXISTING RELAYS
Separate cue channel
Cues by WebSocket or MQTT, stamped to stream time		Any audio pathDepends on a shared clockAnyMIXED PATHS
Cues in the audio
DTMF tones or a watermark		Anything, including satelliteAbout 0.1 sAnyFALLBACK
Under the hood

Technology choices

PacketMatrix

  • Rust, a single binary, with no allocation on the audio thread
  • symphonia and FFmpeg for decoding, cpal or JACK for devices, rubato for resampling
  • LAME, fdk-aac and Opus encoders; Icecast, SRT and HLS outputs
  • axum for REST and WebSocket

PacketDeck

  • SvelteKit (TypeScript), served by the core
  • Tauri desktop wrapper for hotkeys, MIDI, GPIO and Stream Deck
  • Layouts that work on touchscreens, saved per user

Data

  • PostgreSQL for the library, logs, clocks and as-played history
  • SQLite on each node as a local playout cache
  • Media on a NAS or S3, with each node pre-fetching the next hours
Delivery

Phases

Phase 0

Prove the Matrix

Play to two sound cards while streaming, and run it for 72 hours measuring drift and glitches.
Phase 1

Automation MVP

Library import with markers and loudness, the log model, Auto mode, Icecast output, the on-air screen.
Phase 2

Live assist

Assist mode, players with SEQ, the stack, hotkeys, routing, fader start, the studio node with failover.
Phase 3

Scheduling & logs

Clock scheduler or scheduler imports, traffic reconciliation, royalty exports.
Phase 4

Voice tracking

Record against the real outro and intro, including remote voice tracking in the browser.
Phase 5

Networks

Hub output with cues, the affiliate role, cue rules, proof of play.