FAQ

Can I broadcast from Windows?

shiloh-broadcaster requires PipeWire for null-sink creation and the PipeWire-JACK shim for audio capture, so it is currently Linux-only.

shiloh-relay (the listening client) does have Windows builds — it uses cpal for audio output, which supports WASAPI on Windows. Cross-compiled binaries for Windows x86_64 are produced via cross using the x86_64-pc-windows-gnu target.

If you need to send audio from a Windows machine, a workaround is to run a Linux VM with PipeWire and route audio from Windows into the VM via a virtual audio cable (e.g. VB-Cable), then run shiloh-broadcaster in the VM.

What is the maximum latency end to end?

On a wired LAN:

Over WireGuard at 20 ms RTT, add ~20 ms to the relay path. Browser latency is dominated by the 20 ms Opus frame and the browser jitter buffer — network RTT has less effect than for the relay path.

Can I use this for production?

Yes. It is running in production for live events at the time of writing. The relay protocol is intentionally simple (no retransmit, fixed packet size) so there are few failure modes.

The main limitation is that it has not been tested beyond ~10 simultaneous relay clients. The server-side capacity is capped by a compile-time/config max_clients (default 16); beyond that, REGISTER packets receive a REJECT 0x01 (capacity) response.

What bitrate does it use?

Relay protocol (shiloh-relay): raw S16LE, ~1.6 Mbit/s per client at 48 kHz / stereo / 128 frames per packet. This is not compressed.

Browser (shiloh-web-relay): Opus, 128 kbps VBR stereo per feed. All browsers sharing a feed share one encoder — the bandwidth to the server does not grow with browser viewer count.

Do I need a dedicated server?

No, but the server should not be a shared audio workstation. The mixer runs a JACK real-time callback and benefits from a machine with low interrupt latency.

An old quad-core Intel NUC or mini-PC with 4 GB RAM is more than adequate. The bottleneck is usually network bandwidth on the LAN switch, not CPU.

Does shiloh-broadcaster affect audio quality on the sending machine?

No. The null-sink is a PipeWire routing abstraction — it has no effect on other audio devices or applications. Apps routing audio to other outputs (headphones, USB DAC, etc.) are unaffected.

The only observable effect is that a new output device appears in the system audio output list.

What happens if the mixer restarts while broadcasters and relays are connected?

• shiloh-broadcaster: detects session invalidation (the mixer returns a stale session error on the next AUDIO_TX), immediately re-registers without waiting for the full backoff window.
• shiloh-relay: detects no AUDIO packets for > 3 s (or a REJECT), starts reconnect with 1 s initial backoff.
• shiloh-web-relay: same as relay — reconnects per-feed independently.

In practice, a mixer restart causes 3–10 s of silence on relay clients, then audio resumes automatically.

Can I run multiple mixer instances?

Each mixer instance needs its own UDP port (broadcast_port in the TOML) and its own JACK client name (jack_name). They can coexist on the same machine. Broadcaster senders and relay clients each point at a specific host:port — there is no broadcast discovery.

Can I use this with a real jackd instead of PipeWire-JACK?

Yes. shiloh-mixer links against libjack and works with both classic jackd2 and the PipeWire JACK shim. With jackd, omit the LD_LIBRARY_PATH override in the systemd unit (or set it to point at the real jackd libraries instead).

shiloh-broadcaster creates PipeWire null-sinks via pactl, so it requires PipeWire on the sender machine. With a real jackd setup on the mixer server, you can still run shiloh-broadcaster on PipeWire laptops.

How do I add a new audio input channel?

1. Add a [[channels]] block in shiloh-mixer.toml with a unique id, label, and kind.
2. If it’s a broadcaster ingest channel, assign an ingest_slot and add a matching [[ingest.sender]] block.
3. If it’s a JACK hardware input, add a [[autoconnect]] block to wire the hardware port to the channel’s mixer input port.
4. Restart shiloh-mixer.
5. The new channel appears in the web UI on next load.

The web UI shows “offline” for MIDI. Is it broken?

No. “Offline” means no MIDI events have arrived at port 19999 in the last few seconds. Check:

1. Is shiloh-midi-sender running on the keyboard machine?
2. Is UDP port 19999 reachable from that machine? (nc -u server 19999 should not time out.)
3. Does the mixer log show MIDI listener on 0.0.0.0:19999 at startup?

The MIDI system is entirely optional — the mixer operates normally without it.

Can multiple broadcasters send at once?

Yes. The mixer supports multiple simultaneous broadcaster senders up to the slot_count configured in [ingest]. Each sender occupies a contiguous range of slots equal to its channel count. A typical stereo broadcaster uses 2 slots; a 4-channel broadcast desk uses 4.

Each sender must be listed in [[ingest.sender]] with a unique name and non-overlapping start_slot. Senders not in the allow-list are rejected with REJECT_UNKNOWN_SENDER.

Is there encryption?

No. The relay and ingest protocols use raw UDP with no encryption or authentication. Audio is sent as plaintext S16LE.

For WAN connections, use WireGuard to encrypt the tunnel between the broadcaster/relay and the mixer server. See Security.

The WebRTC browser path (shiloh-web-relay) uses SRTP (mandatory in WebRTC), so browser audio is encrypted between the server and the browser.

Does it work over WiFi?

Yes, but wired Ethernet is strongly recommended. WiFi introduces jitter that causes crackling on relay clients. The relay’s --buffer-ms setting can compensate up to a point — try 100–200 ms on a congested WiFi network.

If you must use WiFi, place the mixer server and relay endpoint on the same access point and 5 GHz band. Avoid 2.4 GHz near microwave ovens or busy environments.

Can I record the mix?

Not built-in. The mixer does not write audio to disk. To record the mix:

Option A — JACK capture (low latency):

# Record the main mix output port
jack_capture --port "shiloh-mixer:out_1" --port "shiloh-mixer:out_2" \
  --filename recording.wav

Option B — Ardour:

With the Ardour template installed (see OPERATIONS.md), Ardour’s Master bus receives the mix via JACK. Arm a track on the master and hit record.

Option C — PipeWire loopback:

pw-record --target shiloh-mixer:out_1 recording.wav

Note: recordings start and stop manually. There is no built-in schedule or automatic recording trigger.