Clocking and sample rate

Rate and clock are two different things

It is worth separating them before anything else, because they are easy to conflate:

• The sample rate is a number — 44.1, 48 or 96 kHz. On a Roland desk the operator picks it from the REAC menu. It is a choice, made once, at the mixer.
• The clock is the timing reference everything locks to — who actually generates the ticks. That is a separate setting, and it does not have to be the mixer.

A rig can take its clock from:

• the mixer itself (its internal clock — the common case);
• a stagebox on the REAC segment;
• an external source — Roland desks have a word-clock connector for exactly this, and it is how a REAC rig joins a house clock shared with other digital equipment.

The one hard rule: exactly one clock master on the network. Two devices both trying to be master is the classic cause of clicks, dropouts and links that come and go. If you change the clock source, change it in one place and confirm everything else is following.

The rate is chosen at the mixer regardless of where the clock comes from — the clock source supplies the timing, not the number.

"REAC master" means: you own the clock pace

These are not two roles that happen to coincide — they are the same statement:

Being the REAC master is a way of saying you own the clock pace. Whoever emits the clock is the master.

The owner sends the frames; that emission is the segment's clock, and everything else answers on that grid.

Either end can be the owner. This is not a property of what a device is — a stagebox can own the pace just as a mixer can. It is a configuration, set on each device, and the job is to make sure the two ends agree:

Configure the box and the mixer so that exactly one of them owns the clock.

Two owners on one segment is the classic fault — clicks, dropouts, links that come and go. No owner at all is equally broken: nothing emits, nothing locks.

Whoever owns the pace still has to get its rhythm from somewhere. That is the clock reference, a separate question from ownership:

• its own internal clock — the common case;
• an external word clock — Roland desks have the connector, and it is how a REAC rig joins a house clock shared with other digital gear.

Taking your timing from elsewhere does not change who owns the pace. A mixer locked to house word clock still owns the pace, still grants, still drives the segment. It simply derives the rhythm of that pace from another source.

openmixer needs a real clock before it may own the pace

A Roland desk always has an answer to "where does your rhythm come from" — a crystal on its own board. openmixer does not. It is software on a general-purpose machine, and its rhythm has to come from some device on the PipeWire graph. That makes clock reference an eligibility question for us in a way it never is for a hardware desk:

openmixer may own the REAC pace only if the graph contains a real hardware clock it can follow. We take the best one available and drive the segment from it.

The reason is that our emission is the segment's clock. Every box locks to it. Whatever jitter is in our reference, we hand to the whole rig with the authority of the master — so "a clock exists" is not the bar; "a clock worth propagating" is. Not all of them are:

Why a PLL, and how to see whether you have one

Every digital device keeps time with its own crystal, and no two crystals run at exactly the same speed. Left alone, a stagebox, an audio interface and the computer's graph each tick at their own rate and slowly drift apart; the converters between them absorb the drift, which works, but it is a rig held together by correction rather than by a common clock.

A phase-locked loop is the circuit that makes one device follow another's timing: it compares its own ticks with the reference, steers its oscillator until they line up, and keeps them lined up while filtering the jitter of the reference out of what it passes on. That is what makes a clock worth propagating. A professional interface such as the RME has one, so when it drives the graph, every rate on the graph is steady and the REAC pace derived from it is steady too. A crystal running free has no loop and drifts; a software timer has no oscillator to steer and jitters with the machine's load.

The REAC clock panel tells you which of these the rig is running on. Each segment shows its pace source, from best to worst:

A properly clocked rig shows phc or graph-ref. free-run is a fallback the panel reports so that it never passes for normal: audio still flows, the converters still cope, but the rig is drifting rather than locked, and that is the state to leave before a show.

If nothing better than a software timer is on the graph, the honest configuration is to let something else own the pace — a stagebox owns it perfectly well, and following a real box clock beats leading with an invented one. Free-running as master is an emergency measure, not a default.

This does not restrict us to the machine's own hardware: a stagebox's recovered clock is a first-class reference too. What matters is that the rhythm we emit was measured off real hardware somewhere, not synthesised from a system timer.

What software timing can and cannot do

None of this means software clock discipline is weak — it is how we use a good reference, and it is very good at that. Two axes, and they behave differently:

Frequency accuracy is recovered, not invented. Counting frames over a window and dividing by elapsed time recovers the transmitting crystal to sub-ppm, because a crystal is what is being averaged. This is measured, not theoretical: it is how reac-repacer's PLL nulls long-term drift. So a good reference makes us about as accurate as that reference is. The corollary is the whole point of the rule above — with no crystal in the loop there is nothing to average, and disciplining to a host timer only makes that timer's drift smooth, never right.

Emission phase is bounded by the scheduler, not by the filter. Getting the frame onto the wire at the intended instant is a different problem, and no amount of loop tuning improves it. Commodity hardware is fine on the follower side — a received frame is a tick, so the cadence comes in for free — but the owner side has to place each frame itself. Closing that gap wants TSN hardware launch time (SO_TXTIME offload on i226-class NICs); without it, software timing still carries scheduler wake jitter.

Which is why the follower role is the easy one and owning the pace is the demanding one: as a follower we inherit both axes from the master. As the owner we must supply both — accuracy from a real reference, phase from the machine.

Where this lives in the console: Setup → Clock

The panel's first control is Master / Follower — whether openmixer owns the pace. It is a setting, kept with the session, not something the desk works out from what is plugged in.

• Master lists the devices on the graph that could be the reference, says what each one is (audio interface / onboard codec / display audio / software driver) and which one PipeWire is actually driving from. The desk picks a sane default; you can designate one yourself, and your choice wins — an interface it does not recognise is still an interface. Only the ones that genuinely cannot carry a pace are refused. The sample-rate menu then offers what the segment can run: 44.1, 48 or 96 kHz.
• With nothing on the graph worth propagating, Master is not offered at all. Free-running is available, but only by ticking it explicitly — the panel says what that means.
• Follower shows who owns the pace and the rate we are being given, and the rate menu goes read-only: that number is not ours to choose. The transport still free-runs on the host clock today, so the panel says free-running rather than claiming a lock.

Two owners, no owner, and Dummy-Driver driving the graph all raise a warning in the header's warnings panel, so they are visible without the Setup page open.

The 192 kHz limit is physical

REAC runs over 100 Mb Ethernet, and the downstream broadcast is 1492 B per frame regardless of how many inputs the box has. That fixes the bandwidth per direction (the link is full duplex, so downstream and upstream have separate budgets):

At 48 kHz the downstream uses about half the link. At 96 kHz it uses nearly all of it — tight, but workable, because the traffic is isochronous with one talker per direction and no contention to lose capacity to. At 192 kHz it would need roughly twice the link, so it cannot work on 100 Mb hardware. That is arithmetic, not a limitation of this software: it would require gigabit stageboxes, which do not exist in this product line.

A practical planning consequence: at 96 kHz the segment has very little spare headroom. Keep the REAC link on its own dedicated, non-mirrored port (see Wiring and NIC) — a mirrored port is already the wrong topology, and at 96 kHz there is no capacity to absorb anything unexpected.

44.1 kHz: supported, but check your plugins

The transport syncs at 44.1 kHz — this has been done on the rig. Whether you want to is a different question, and a third question again is whether your plugins behave there: some plugins hold a buffer sized for 48 kHz and report a different latency at 44.1 kHz than their behaviour at every other rate would predict. That is a plugin matter, not a transport one.

Setting the graph rate

The rate is a PipeWire property of the whole graph, not an openmixer setting, and it cannot be changed on a running graph in a way the mixer can force behind your back — the mixer's clock controls report what the graph is actually doing.

The rig's rate is a console control, not a configuration file: the clock on the Setup page sets the graph's rate from the rates the hardware declares, and the console keeps it there across restarts because it is part of the session. A REAC segment keeps its own pace, chosen in the REAC clock panel, 44.1, 48 or 96 kHz, and the daemon converts between the two. Editing PipeWire's configuration by hand is not needed and is not how this console is meant to be run.

Then restart the session's PipeWire and the mixer:

When there is other hardware on the graph

If the rig also has an audio interface — an RME, a USB card — it is on the same PipeWire graph, and it must agree. Two rules:

• Set every device to the same rate. A device that disagrees will be resampled.
• An interface that is present but idle can still be elected the graph's driver, which is a well-known source of xruns. If you see dropouts on a rig with an unused capture device, see xruns and driver election.

That interface is also the rig's clock reference when openmixer owns the REAC pace — see openmixer needs a real clock before it may own the pace.

Checking

pw-metadata -n settings | grep clock

The mixer shows the same facts in its telemetry panel: the buffer quantum, the sample rate and a live xrun counter. If the rate there is not 48000 with a stagebox connected, fix that before chasing anything else.