Recovering a Ruby Console When It Loses Synchronisation
A Ruby console losing synchronisation can present as silence, clicks, unstable faders, or a control surface that appears disconnected from the audio engine. The visible symptom is often less useful than the timing relationship between the console, Power Core nodes, network switches, and any external source or destination.
A calm, staged response protects the programme output and prevents a simple clock problem from becoming a wider outage. Australian stations also need to consider local studio layouts, mixed time zones, remote contribution links, and ACMA obligations when deciding whether to switch to backup audio or take equipment offline.
Recognise The Failure
First establish what has actually failed. Check whether every channel is affected, whether only one source has disappeared, and whether the Ruby surface still responds to fader movement and source selection. Listen for periodic ticks or mutes, which often indicate a sample-clock problem, rather than a complete network failure.
Look at the console’s status information, Power Core indicators, VisTool pages, and any available network management interface. Record the time, affected sources, alarm text, and recent changes. In a Sydney or Melbourne station, a live breakfast programme may leave little room for experimentation, so move to the approved backup path before investigating a live signal chain.
Check Clock And Network Paths
Confirm the selected synchronisation source and whether the system reports it as locked. Depending on the design, timing may come from a PTP grandmaster, an external reference, or a network audio device. A failed grandmaster, incorrect PTP domain, mismatched profile, or switch configuration change can cause several devices to lose lock together.
Inspect Ethernet links, switch port status, fibre converters, and redundant connections. Avoid repeatedly unplugging cables while the system is active, because that can create a second fault. If a remote studio in Perth connects to a main facility on the east coast, separate local clock health from WAN transport issues; a healthy local Ruby may still receive unstable or delayed contribution audio.
Isolate The Fault
Determine whether the fault follows a device, a port, or a signal path. If permitted by the station’s engineering procedures, move a suspect source to a known-good input or compare the affected output with a monitoring bus. A single failed Power Core connection points to a different remedy from a system-wide PTP alarm.
Do not change several network, clock, and configuration settings at once. Capture screenshots and configuration details before making a correction. This is especially important where Ruby is integrated with RƎLAY virtual radio tools, automation, codecs, or theatrical and live-performance equipment that may share network infrastructure.
| Observation | Likely area | Safe first check |
|---|---|---|
| All audio has clicks or mutes | Master clock or PTP | Confirm grandmaster and lock status |
| One node is unavailable | Power Core or network path | Check power, link LEDs, and switch port |
| Surface responds slowly | Control network or host service | Check latency and recent network changes |
| Only one source is silent | Routing, input, or source device | Compare with a known-good source |
| Audio is stable but control is lost | Control connection or software service | Check Ruby and VisTool connectivity |
Restore In A Controlled Order
If the reference clock is faulty, restore or replace that reference first. Allow the grandmaster and network timing services to stabilise before restarting downstream devices. A sensible order is clock source, core network, Power Core nodes, Ruby surface, and then connected control or automation services. Follow the site’s Lawo documentation and approved recovery runbook rather than applying a generic reboot sequence.
When a full restart is necessary, protect the broadcast chain with a confirmed backup source. This might be a playout server, a codec feed, or a local emergency programme path. In Brisbane, where daylight-saving changes do not apply while other Australian markets do change their clocks, verify that the incident is not being confused with a scheduling or automation time-base issue.
Verify Audio And Operational State
After synchronisation returns, check more than the green status indicator. Monitor analogue and digital outputs, cue and talkback, mix-minus feeds, record buses, loudness processing, and any feeds delivered to transmitters or streaming encoders. Confirm that routing and gain values have not changed during recovery.
Review the system for hidden consequences, including a source that remained muted, a failed redundant link, or an automation connection that did not reconnect. If the console serves a casino, hotel, or other venue, separate operational audio from guest-facing content and confirm which feed is live; a casino travel feature may be relevant to venue content planning but should never be mistaken for an engineering status source.
Prevent A Repeat Incident
Once the service is stable, save the alarm history, switch logs, PTP information, and configuration snapshots. Note the exact recovery sequence and identify whether a software update, cable change, power event, or network maintenance preceded the loss of sync. Keep an updated diagram showing Ruby, Power Core, switches, timing sources, codecs, and redundancy links.
Australian broadcasters should align the recovery record with internal compliance procedures and ACMA expectations for reliable, properly controlled services. Test the backup path during a planned maintenance window, especially before major sports coverage or outside broadcasts. The practical final step is to schedule a controlled sync-loss drill and record the measured time from alarm to confirmed on-air recovery.
