When does a hotel actually need multiple PCs for music?

There are three signals. First, when zone count exceeds ~16–20 (a single PC + multi-channel audio interface practically tops out around there). Second, when zones are physically far apart — a beach club 200 m from the main building can't be reliably cabled to a single audio source. Third, when redundancy matters — large resorts often run failover nodes specifically so a single PC crash doesn't silence the entire property.

What's master-node architecture?

One PC is the master (or controller) that holds the central configuration — schedules, playlists, user accounts. Additional PCs are nodes that hold local copies of music files and audio interface hardware. The master sends control commands ("play track X in zone Y") and the node plays from its local cache. This works robustly even if the network between master and node briefly drops, because the node has the audio locally and just needs control instructions.

Do nodes keep playing if the master goes offline?

Yes, if the system is designed properly. A well-designed node continues playing its current scheduled playlist from local cache even if the master is unreachable. It will not be able to receive new schedule changes or playlist updates until the master is back online, but the current music keeps running. This is the failover property that makes multi-PC setups valuable beyond just zone count.

What network connection between master and node — Wi-Fi or wired?

Always wired Ethernet. Wi-Fi between master and node will eventually fail (microwave interference, AP reboots, channel congestion), and when it does, your nodes lose touch with the master. Even if the node keeps playing locally, you've created an unnecessary failure vector. A single Cat6 cable to each node location, ideally on its own VLAN, costs almost nothing and eliminates the entire class of problem.

How many nodes can one master handle?

In practice, 5–10 nodes is comfortable. Above that, the master becomes a single point of contention. For very large resorts (50+ zones across multiple buildings), a tiered architecture is sometimes used — one master, multiple "sub-masters" each handling a building's nodes. But this is rare; most large hotels manage with 3–6 nodes.

What happens to scheduled announcements if a node loses connection?

Depends on the announcement design. If announcements are pre-stored on the node, they play on schedule from local cache. If announcements are streamed from master in real time (live paging), they fail when the master is unreachable. Production systems pre-cache scheduled announcement audio on each node specifically to avoid this dependency.

Setting Up Multi-PC Music Networking in a Resort: The Master-Node Guide

If you're planning audio for a hotel larger than ~150 rooms, or a resort with multiple disconnected buildings (beach club, spa pavilion, sports facility), you'll eventually need more than one PC running your audio system. This guide covers when, why, and how to scale to a multi-PC master-node architecture without breaking your operational stability.

The guide is vendor-neutral. Rafilis makes Rafilis Multizone, which includes built-in master-node networking, but the architecture principles below apply to any commercial system that supports distributed deployment.

For the broader context on hotel audio, our complete guide to hotel background music systems covers single-PC and small-property deployments. This article focuses specifically on scaling beyond what a single PC can handle.

When a single PC is no longer enough

A typical Windows PC with a multi-channel USB audio interface (RME UFX III, Focusrite Clarett+ 8Pre with ADAT expansion, etc.) can drive 14–20 independent audio zones reliably. This is enough for:

A 100-room boutique hotel with 8–12 zones
A mid-sized restaurant chain
Most single-building properties

Where it stops being enough:

Reason 1 — Zone count exceeds what one interface offers

If your audio interface has 16 output channels and you need 20 zones, you have a problem. You can either add a second interface to the same PC (sometimes possible via ADAT expansion, sometimes not) or add a second PC. The second PC is usually simpler and more reliable.

Reason 2 — Physical distance between zones

Balanced analog audio over Cat5e or shielded multicore degrades audibly past about 50–80 metres. Past 100 metres, you're losing high frequencies enough that guests will notice. If your property has a beach club 200 metres from the main building, you cannot reliably cable an analog signal across that distance.

Three options at this point:

Run digital network audio (Dante or AVB over Ethernet — Cat6 reaches 100 m per segment, then needs a switch). Expensive infrastructure.
Run a dedicated fiber backbone with audio converters. Even more expensive.
Put a node PC at the remote location with its own audio interface. Cheapest by far. The audio signal only travels a short distance — from the node PC to its local amplifiers and speakers.

For most hotel and resort scenarios, option 3 wins.

Reason 3 — Redundancy / failover

A 250-room resort with a single audio PC has a single point of failure. If that PC crashes, hangs, or needs a Windows Update, the entire property goes silent. For many properties, this is unacceptable.

Multi-PC architecture with failover means: if the master PC goes down, the nodes continue playing their current playlists from local cache. The system degrades gracefully — you lose the ability to change schedules or playlists until the master is back, but the current music keeps running.

Master-node architecture explained

Let's define terms clearly, because vendors use them inconsistently.

Master PC (Controller):

Holds the central configuration database (zones, playlists, schedules, users)
Hosts the admin UI / web interface
Sends control commands to nodes via network
Coordinates time-sync, license checks, software updates

Node PC (Audio Output Endpoint):

Has its own multi-channel audio interface driving local zones
Holds a local cache of the music library (replicated from master)
Receives control commands from master and executes them
Plays audio locally without sending audio over the network (only control packets travel)

The critical architectural choice: does audio travel over the network, or does each node have its own audio files?

Systems that stream audio from master to node in real time over the network are vulnerable to network jitter, Wi-Fi instability, and any kind of bandwidth contention. Even on a wired LAN, sending high-quality audio to 10 nodes creates 5–15 Mbps of sustained traffic per channel — manageable, but fragile.

Systems that pre-cache audio on each node are far more robust. The network carries only control packets (a few kbps), and audio is played from local SSD on the node. If the network drops briefly, the audio doesn't even notice.

Rafilis Multizone uses the local-cache model. So do most well-engineered enterprise systems (Bose CSP, BSS Soundweb in distributed mode). Avoid systems that require continuous audio streaming between nodes unless your network is exceptionally robust.

What runs on each PC

Master PC (typical configuration)

Hardware: standard business desktop, 16 GB RAM, 500 GB SSD, wired Ethernet
Audio interface: optional (master can be audio-less if it doesn't drive zones directly)
Network: wired Cat6, ideally on a dedicated audio VLAN
Location: IT room or back-of-house with controlled climate, UPS-backed power
Backup: nightly automated backup of configuration database

Node PC (typical configuration)

Hardware: small form-factor PC (Intel NUC, Lenovo Tiny, Mac Mini for cross-platform setups), 8 GB RAM, 250 GB SSD
Audio interface: multi-channel USB interface (4–16 channels depending on local zone count)
Network: wired Cat6 back to master's switch
Location: AV closet near the local zones — beach club back room, spa technical area, conference centre rack
Power: surge-protected, ideally UPS-backed

The node PCs don't need to be powerful. They just need to reliably play audio files and respond to network commands. Underpowered hardware is fine; overpowered hardware is wasted.

Network requirements

Master-node communication needs:

Wired Ethernet between all PCs. Cat5e minimum, Cat6 preferred.
Single LAN subnet OR routable network with explicit firewall rules. Master and nodes need to reach each other on specific ports (typically TCP/UDP in the 5000-9000 range, vendor-specific).
UDP broadcast permitted on the local subnet for node auto-discovery. If broadcast is blocked, you'll need to manually configure each node's master IP.
Stable DHCP or static IPs. If a node's IP changes daily because of a short DHCP lease, the master loses sight of it intermittently.
NTP enabled and synchronised. Schedules depend on accurate time. If master and nodes drift, schedules fire at wrong times.

Bandwidth

If audio is cached locally (the right design), bandwidth between master and node is minimal — control packets and occasional sync. A few hundred kbps sustained, with bursts during music library updates. Any modern LAN handles this trivially.

If audio is streamed live (the wrong design for hospitality), expect 1–10 Mbps per channel per node. A 16-zone node receiving live audio could need 30+ Mbps sustained. Saturates cheap consumer Wi-Fi or aging switches.

Latency and jitter

For control-only traffic, network latency up to 50 ms is fine. Jitter doesn't matter — schedule commands are sent in advance.

For live-audio-over-network systems (Dante, AVB), you need professional network gear: managed switches, QoS for audio packets, and tight latency control. This is the world of professional AV networking and significantly increases install complexity.

Failover behaviour — what should happen when master goes down

A well-designed multi-PC system handles master outages gracefully. The expected behaviour:

Immediate (0–5 seconds after master loss):

Nodes notice they've lost connection to master
Nodes continue playing the currently-playing track from local cache
Node UI shows "offline" or "master unreachable" indicator

Short-term (1–30 minutes):

Nodes complete the currently-playing playlist
Scheduled playlist swaps occur on time if the schedule was pre-distributed
New songs continue if local cache has them

Medium-term (30 min – 24 hours):

Nodes continue running on the last-known schedule indefinitely
Local UI on nodes may be limited (no admin functionality until master returns)
Logs accumulate locally and sync when master returns

When master comes back:

Nodes auto-reconnect (no manual intervention)
Configuration changes made on master while offline propagate to nodes
Logs sync upstream
System resumes normal operation

This graceful degradation is the value of multi-PC architecture. If a single PC handled everything and crashed, the entire property would go silent. With node-local caching, only the ability to make changes is affected — the current music keeps playing.

Real-world failure modes in multi-PC setups

"All the nodes show offline at the same time"

Cause: master PC crashed or rebooted, OR the network between master and nodes failed (switch crash, VLAN misconfiguration, accidental cable disconnect).

Fix: check the master first. If master is healthy, walk the network — start with the switch, then the cables.

"Some nodes are online, one is offline"

Cause: the offline node has its own problem — PC frozen, audio interface USB disconnect, local power loss, cable to local switch broken.

Fix: physically inspect the offline node. If unreachable, restart it.

"Audio interface stopped working after Windows Update"

Cause: Windows Update sometimes resets audio device settings or changes default sample rates.

Fix: in the multi-zone software on the affected PC, re-select the audio interface. Disable automatic Windows updates on production audio PCs (or at minimum, schedule them for off-hours).

"Schedules are firing 10 minutes late on one node"

Cause: NTP sync broken on that node. The node's clock has drifted relative to master.

Fix: ensure NTP is enabled. If the IT firewall blocks NTP traffic, configure a local NTP source on the master PC.

"Music plays for a few minutes then stops"

Cause: usually local music file integrity. The node may have a corrupted cached file that fails to play to completion. Multi-zone software should handle this gracefully (skip and log), but some implementations don't.

Fix: trigger a music library re-sync from master to the affected node. Update software if the bug is in the multi-zone player.

"One zone has crackle / dropouts; others are fine"

Cause: USB bus contention on that node's PC. The audio interface is sharing a USB controller with another device under heavy load.

Fix: move the audio interface to its own USB controller (different USB port group, not just a different jack). Some PCs have multiple USB controllers; some have only one.

Real-world example: 280-room resort deployment

A typical 280-room beach resort might be structured like this:

Building / area	PC role	Zones
Main building IT room	Master + Node 1	Lobby, Reception, Main Restaurant, Lobby Bar (4 zones)
Spa pavilion (50m away)	Node 2	Spa Reception, 3 Treatment areas, Sauna (5 zones)
Beach club (200m away)	Node 3	Beach bar, Pool deck, Beach beds, Outdoor restaurant (4 zones)
Conference centre (separate building)	Node 4	6 conference rooms, Conference lobby, Foyer (8 zones)

Total: 4 PCs, 21 zones. A single PC could not reliably drive 21 zones, and the physical distances make cabling impossible.

Each node uses a dedicated Cat6 line back to the main IT room's switch. NTP is sourced from the master. Music library is ~80 GB, replicated to each node's local SSD. Total network traffic between master and nodes is < 1 Mbps sustained.

If the master goes down for any reason, all 21 zones continue playing. Schedules can't be edited until master returns, but the property remains operational.

How Rafilis Multizone handles multi-PC

Rafilis Multizone's master-node networking is built around the local-cache model described above. Key behaviours:

Auto-discovery via UDP broadcast on the same subnet — no manual IP configuration in most setups
Local music cache on every node — audio plays from local SSD, network carries only control
Graceful master-offline handling — nodes continue playing scheduled content
Auto-reconnect — nodes rejoin the master when network restores
Per-zone PC assignment — admin UI shows which PC drives which zone

The setup process is:

Install Multizone on master PC, configure zones and schedules
Install Multizone on each node PC, set role to "Node" in settings
Nodes auto-discover the master on the same network
Master admin UI shows nodes as online, lets you assign zones to specific node audio outputs

Total setup time for a typical 4-PC deployment: 2-3 hours assuming network infrastructure is already in place.

When NOT to use multi-PC

Multi-PC adds complexity. It's worth it for properties that meet the criteria (zone count, physical distance, redundancy need). For smaller properties, it's overkill:

A boutique hotel with 8 zones in one building: single PC.
A restaurant chain with 6 venues each having 3 zones: single PC per venue, no master-node needed.
A 50-room hotel where downtime tolerance is high: single PC.

If you're considering multi-PC because "it sounds more professional," you're probably over-engineering. Real reasons (zones, distance, redundancy) come from operational requirements, not aspirational marketing.

How to plan audio zones for a 100-room hotel — zone mapping comes before scaling decisions
Multi-zone audio for hotels: how it works — architecture from signal flow upward
ASIO vs WASAPI for hospitality audio — driver choice per node

Multi-PC scaling is one of those topics that sounds intimidating but is mechanically straightforward. The hard part is acknowledging when you've outgrown a single PC. Once you accept that, the architectural choices are clear: local-cache, wired Ethernet, simple master-node topology. Resorts that get this right run for years with minimal AV intervention.