Hardware Requirements

Hardware Requirements

Zeus is a real-time DSP application. CPU stalls, GC pauses, and network jitter all map directly to popping audio or detuning. The bare minimum to launch is much lower than what gives you a smooth, low-latency operating experience. This page calls out the difference.

If you want a one-line answer: Apple Silicon Mac (M1 or better) with 16 GB RAM, 1 GbE wired to the radio, and a Focusrite-class USB audio interface. Everything below is the long version.

Sizing tiers

Component	Floor (no hiccups)	Recommended (great experience)	Pro / contest-ready
CPU	M1 Mac, modern 6-core x86 (i5-12500+, Ryzen 5 5600+), GB6 single-thread ≥ 2000	M1 Pro / M2+ Mac, or 8-core+ x86 (i7-13700+, Ryzen 7 7700+), GB6 single-thread ≥ 2500	M2 Pro/Max, M3+, Ryzen 9 / Threadripper, GB6 single-thread ≥ 3000
RAM	8 GB	16 GB	32 GB
Storage	NVMe SSD, 20 GB free	NVMe SSD, 100 GB+ free	Dedicated NVMe for backend logs / recordings, separate from OS drive
GPU	WebGL2 + EXT_color_buffer_float (any integrated GPU since ~2017)	same	same
Network (radio link)	1 GbE wired, low-latency switch	1 GbE wired, direct or single-switch-hop, no heavy traffic sharing the switch	Dedicated VLAN for the radio, QoS prioritising the radio's IPs, or direct cable
Network (browser, split-host)	1 GbE wired (Wi-Fi works but you'll see waterfall stutters under interference)	1 GbE wired	Wired on the same switch as backend
Audio (mic / monitor)	Built-in / class-compliant USB, tested at OS default buffer with no underruns	Dedicated USB interface — Focusrite Scarlett, MOTU M2/M4, similar; ~3 ms latency	Same class with discrete monitor output, hardware mute toggle
Display	1080p	1440p, 27"+ (the panadapter wants real estate)	Dual-monitor: 27" 1440p main + secondary for log / Discord / AI tools
OS tuning	CPU governor performance (Linux), disable App Nap (macOS), High-Performance power plan (Windows), Wi-Fi power-save off	Same + dedicated user (no heavy background apps), backend at high priority, screen saver / auto-update disabled during ops	Real-time kernel priority for backend, all background services audited
Power	AC-powered host (laptops on battery throttle)	AC-powered, UPS for radio + host	Same plus UPS for network gear

Hard constraints (non-negotiable at any tier)

• WebGL2 + EXT_color_buffer_float — the panadapter won't render without it. Any integrated GPU since ~2017 satisfies this. Binary check.
• Wired Ethernet to the radio. Wi-Fi to the radio is never acceptable — even great Wi-Fi has jitter spikes that shred IQ. Wi-Fi to the browser (split-host setup) is fine.
• No spinning rust on the radio path. SSD/NVMe required. Even occasional swap to spinning disk = audible pops.
• AC power, not battery. Laptops on battery downclock under power-management heuristics; you'll hear the throttle as audio glitches.

Why the "Recommended" tier earns its name

Going from Floor → Recommended is where user-visible smoothness comes from:

• Panadapter at 60fps with no jank, even during band changes, mode switches, or transients. On Floor you'll see occasional micro-stutters; on Recommended it's glassy.
• Filter changes are instant. Drag the filter ribbon and audio re-bandpasses without a perceptible click. On Floor you'll hear the filter "chunk" as WDSP catches up.
• PureSignal + CFC + NR4 simultaneously stays clean. On Floor that combo can spike CPU to 80%+ during transmits; on Recommended it's a non-event.
• Long-session stability. 8-hour contest ops without thermal throttling, GC pauses, or memory pressure. The 16 GB RAM matters a lot here — gives the OS file cache room to breathe so disk I/O never blocks the audio thread.
• Mic latency you don't notice. Dedicated USB interface gets you ~3-5 ms round-trip. Built-in audio is more like 10-25 ms. The difference is "feels live" vs "feels delayed."

Common pitfalls (each item is a real problem we've seen)

• Cheap unmanaged switches with shallow buffers drop UDP packets under burst load. Won't show in throughput tests; only as occasional pops. Use a managed switch on the radio path or a switch known to have deep buffers.
• Thermal throttling on small-form-factor PCs. A box that benchmarks fine can drop frames after 30 minutes when the CPU starts to throttle. Verify with sustained-load testing, not single-shot Geekbench.
• macOS App Nap / Energy Saver silently throttles backend processes that lose focus. Disable it for the Zeus backend, or run the backend as a launchd service.
• Linux ondemand governor ramps clock up/down on demand, exactly the wrong behaviour for real-time DSP. Set performance governor.
• Other apps on the same Wi-Fi as the browser-to-backend link. A single 4K video stream on the same SSID can spike browser-to-backend latency. Wired is the safer choice even on the browser side.
• Software-defined radio + virtualised host. VMs add jitter. If you're running Zeus in a VM (e.g. on Unraid), pin CPU cores and use SR-IOV or bridged networking, not NAT. Better: bare-metal.

Operating-system notes

• macOS — easiest path. CoreAudio is the reference latency target. Disable App Nap for the backend and you're done.
• Linux — best with performance CPU governor, RT kernel for high-end ops, and pinning the backend's network interrupts to a dedicated CPU. Worth it if you're chasing the lowest possible latency.
• Windows — works but requires more tuning. High-Performance power plan, disable Game DVR, set the backend process priority to High. ASIO drivers on the audio interface help a lot.

---

If you're not sure where you land on the chart, run Zeus on what you've got and check the Troubleshooting page if you hit audio hiccups, panadapter stutters, or unusual CPU load. Most issues map to one of the rows above.