Use Cases

1. Live church / event stream

A typical Sunday service setup:

  • Studio laptop (front-of-house): runs shiloh-broadcaster --name studio --channels 2, pushing a stereo pre-fader feed from a DAW.
  • Guest laptop (stage piano or laptop presenter): runs shiloh-broadcaster --name guest --channels 2.
  • Server (stg-srv001): shiloh-mixer assembles all inputs, applies gains and mute, and drives:
    • Main bus → USB DAC → PA system amplifier.
    • Monitor bus → Scarlett outputs → in-ear mix for performers.
    • Browser relay → live stream embed on the venue website (via shiloh-web-relay and a WHEP player).
  • Pi relay in the monitor world: shiloh-relay --server stg-srv001:5005 --name pi-relay assigned to the Monitor feed — performers hear the mix with no additional hardware.

Three sources, three listener types, one server. No proprietary network card required.

2. Home studio multi-room monitoring

You have a workstation running a DAW in one room and want to hear the mix in the kitchen or bedroom without running cables.

  • On the workstation: shiloh-broadcaster creates a PipeWire null-sink. The DAW routes its master output to the null-sink. Audio flows to the mixer on the same machine (loopback) or across the LAN.
  • In each room: a Raspberry Pi or old laptop running shiloh-relay with --buffer-ms 20 for low jitter. Each room gets the mix with ~5–10 ms additional latency.
  • From any phone or tablet on your Wi-Fi: open the browser listener at http://server:8889/listen for a ~300 ms delayed stream — acceptable for casual monitoring.

3. Remote broadcast from a laptop to a central mix hub

A journalist or musician is at a remote location (connected via WireGuard) and needs to send audio to the studio mix server.

  • The remote laptop runs shiloh-broadcaster --server studio.vpn:5005 --name remote --channels 2.
  • The null-sink appears as a regular PulseAudio output in the system. Any app (browser, audio interface, DAW) that outputs to it is automatically captured and sent to the mixer.
  • On the server, the remote channel appears in the web UI like any local source. Level adjustments and muting are done from the browser.
  • Latency over WireGuard on a 20 ms RTT link: approximately 25–35 ms one-way (propagation + 3 ms packet buffer).

NOTE: The broadcaster reconnects automatically with exponential backoff (1 s → 30 s). If the WireGuard tunnel drops, audio resumes within 1–2 seconds of the tunnel recovering — no manual intervention needed.

4. Low-latency headphone monitoring for remote musicians

A musician is in a different building (same WireGuard subnet) and needs to hear the mix while playing along.

  • The musician’s machine runs shiloh-relay --server studio.vpn:5005 --name musician-room --buffer-ms 10.
  • In the mixer UI, the session is assigned to the Monitor or Cue feed (which ignores the main mute — the musician hears everything including their own channel).
  • Latency from source capture to headphones: typically 10–20 ms on a wired LAN, 30–50 ms over WireGuard at typical intra-city RTTs.

For performers who need absolute minimum latency, --buffer-ms 5 is possible on a quiet LAN. Reduce it until you hear dropouts, then step back up by 5 ms. The relay will log [jitter] underrun on stdout when the buffer is too small.