Best practice for adding a subwoofer to an existing zone (sendspin)

[tobsch]

Question

What's the best way to add a subwoofer to an existing zone that already has a sendspin output assigned?

My Setup

• Raspberry Pi 5 running lox-audioserver with sendspin clients for each room
• Wohnzimmer zone with output room_wohnzimmer (stereo speakers via ALSA on the main Pi)
• A separate Raspberry Pi Zero with a HiFiBerry DAC connected to a subwoofer amplifier
• Subwoofer runs its own sendspin client (subwoofer_wohnzimmer) connecting to the same lox-audioserver

Problem

Each zone only supports a single sendspin output (output.clientId), so I can't assign both room_wohnzimmer and subwoofer_wohnzimmer to the Wohnzimmer zone.

What I've Considered

1. Groups — the config has "groups": { "mixedGroupEnabled": false } and "groups": [] in rawAudioConfig. Could groups link a subwoofer zone to the main zone so they always play together?
2. Multiple outputs per zone — Is there a way to assign multiple sendspin clients to one zone?
3. Different approach entirely — Should the subwoofer not be a separate sendspin client at all?

Config Reference

Current Wohnzimmer zone config:

{
  "id": 5,
  "name": "Wohnzimmer",
  "output": {
    "id": "sendspin",
    "clientId": "room_wohnzimmer"
  }
}

What would be the recommended approach to add a subwoofer that receives the same audio as the main speakers in this zone?

[anlx-sw]

i would also be interested in how to achieve this - although with another use case.

i use ledfx for visualizations - and current releases of ledfx support sendspin for audio input. so like with your subwoover i would like to add a second sendspin client as an output to a zone. i tried to use the "audio player fixed group" in loxone config to sync the music with the ledfx zone - but this didn't work at all - i think lox-audioserver is currently not supporting the loxone "audio player fixed group"

workaround:
what did work for me was to create two audio players in loxone config, assign the corresponding sendspin clients in lox-audioserver. then i could create a "dynamic group" in the loxone app (bottom left corner in loxone app). this did work and i could get visualizations and music working - although i think this is not a good permanent solution.

[tobsch]

maybe @rudyberends or @mr-manuel have ideas :) ? would love to get started with the woofer hinthint :)

[tobsch]

This is now implemented — a zone can drive multiple sendspin clients via output.clientIds: string[] (legacy single clientId still works):

• Backend: feat(outputs/sendspin): support multiple clients per zone #285 — SendspinOutput/factory accept clientIds[] (array or comma-separated), fanning one zone's PCM out to N synced SendspinSessions. Exactly your subwoofer case.
• Admin UI: lox-audioserver/adminui#5 — the zone output modal's sendspin client picker is now multi-select (was single-select).

Your Wohnzimmer + subwoofer setup becomes:

{ "id": 5, "name": "Wohnzimmer",
  "output": { "id": "sendspin", "clientIds": ["room_wohnzimmer", "subwoofer_wohnzimmer"] } }

Verified on a Pi 5 (lox 4.0.0-beta.13 with both patches): zone Esszimmer → ["room_esszimmer","room_kueche"], both clients played the same source time-synced.

[rudyberends]

To be clear on the capability: one zone → main speakers + subwoofer, time-synced is legitimate and worth supporting. But after reviewing PR #285 I don't want to merge it as-is — it solves this at the wrong layer:

It builds a second fan-out implementation alongside one that already exists. SendspinOutput already mirrors every scheduled frame to sendspinGroupController, which does exactly this (one leader's PCM → N sendspin clients, with late-join snapshot, PCM-forcing for mixed codecs, per-client connection handling). #285 reimplements that concept inside the output — two parallel code paths to maintain.
The "parity with Snapcast" argument doesn't hold architecturally. Snapcast gets multi-client almost for free: the audioserver registers one stream + a clientIds[] map and snapserver does the fan-out and per-client sync. Sendspin has no equivalent primitive — there's only sendPcmFrameToClient (per client); the protocol's "group" is a UI/control concept, not audio distribution. So #285 has to drive N independent frame pipelines from the audioserver, which is a much heavier and riskier surface than the framing suggests.
The new min-capacity backpressure model couples the zone's single anchor/timeline to the slowest connected client. Sync between main and sub already comes from the server-time timestamps, not from send-pacing — so that machinery isn't needed for sync, and it means a weak client (e.g. a Pi Zero subwoofer) could throttle the main room.

So I will implement this myself, riding the existing mirror path rather than a parallel fan-out: the main client stays the single pacing/anchor authority, and extra clients join as best-effort satellites of the zone (no separate Loxone zone or manual group needed — which is the permanent setup you're after). I'll keep this issue updated as that lands.

[rudyberends]

Update: the backend for this is now implemented on dev (commit ccfae2b). Thanks @tobsch and @anlx-sw for the detailed use cases — they shaped the design.

Heads-up on config: it landed as clientId (the primary) + a separate satellites list, not the clientIds: [...] form mentioned earlier in this thread (that was from an unmerged PR and never shipped — don't copy it, it won't work).

⚠️ The web admin doesn't expose this yet, so for now you set it manually in the zone's output config. The Admin UI satellite picker (multi-select) will land in the upcoming 4.0.0 release.

Your Wohnzimmer + subwoofer setup:

{
  "id": 5,
  "name": "Wohnzimmer",
  "output": {
    "id": "sendspin",
    "clientId": "room_wohnzimmer",
    "satellites": ["subwoofer_wohnzimmer"]
  }
}

A subwoofer often needs its own phase/delay trim relative to the mains, so each satellite can carry its own latency:

"satellites": [{ "clientId": "subwoofer_wohnzimmer", "latencyMs": 12 }]

(A comma-separated string "satellites": "subwoofer_wohnzimmer" also works.)

How it behaves

• The primary speaker and each satellite are independent Sendspin clients. They play the same PCM, time-synced via the protocol's server timestamps (not via send-pacing) — so a 2.1 setup stays in sample-sync.
• Satellites are listen-only and best-effort: a slow/weak satellite (e.g. a Pi Zero subwoofer) never throttles the main room, and if a satellite drops the room keeps playing. They follow the zone's volume and get their own static-delay.
• It also works when the zone's main output is a Cast device running the Sendspin receiver.

@anlx-sw — your LedFX case is covered by the exact same mechanism: add the LedFX client as a satellite and it receives the same audio for visualizations, no separate audio player + dynamic-group workaround needed:

"output": { "id": "sendspin", "clientId": "room_x", "satellites": ["ledfx_x"] }

Note: for two equal speakers in one zone (true multiroom), groups remain the right tool — satellites are specifically for a primary + listen-only extras like a sub or visualizer.