Guides
The guides give the steps for the three tasks this operator exists for: the install, the claim that plays sound to an output, and the claim that pairs a monitor’s speakers with that monitor’s screen.
How the pieces fit
Every guide moves through the same four Dynamic Resource Allocation (DRA) objects, so here is the whole arrangement once.
The operator publishes what exists. Its pod on each node writes one
ResourceSlice, the inventory the scheduler reads. It has one
device for each physical output, named like card0-pcm3, with the
facts about it as attributes, such as the sink a stream targets and
the monitor-pairing identity monitor.liken.sh/id.
On a machine whose radio the Bluetooth operator publishes a media bus for, the same slice holds one device for each paired Bluetooth speaker, named by its MAC address. Everything below applies to a speaker unchanged.
A DeviceClass names a kind of device a workload can ask for. A
class is cluster policy, so you create it yourself: audio-output,
the class that covers every device this driver publishes.
Install the operator gives its YAML. A
class can also be specific, with the selector in the class itself, so claims write
none; Generic or specific
shows both grains.
A workload asks with a ResourceClaim, or with a
ResourceClaimTemplate when each pod of a Deployment needs a
device of its own. The claim names the class, and it narrows the
class with a selector: an expression in
Common Expression Language (CEL)
over a device’s attributes, such as the speakers of one monitor or
any analog jack.
The scheduler matches the claim against the slices, allocates one matching device, and places the pod on that device’s node. When the pod starts, this driver delivers the device to the container: the PipeWire socket, and the name of the sink its streams must reach.