Query on Sync

[Rowr21]

Hi,

Firstly, thanks a lot for this. It is slick and polished and an awesome addition to my smart home!

I was just wondering for "True Multi Room Sync" if this depends solely on manual latency configuration? I am using the docker deployment, and have added my 2 bluetooth speakers to a sync group in MA. I have applied a manual latency difference between the 2 to try sync them. However, when synced on 1 song, it may change on the next? I cant seem to keep consistent sync, and quality playback.

I have trouble syncing external sendspin devices too, ie non bluetooth ones?

Am I missing something?

Thanks!

Rowan

[Rowr21]

Also, would you recommend multiple BT adapters for multiple speakers? I notice performance drops significantly when going from 2 to 3 speakers on the 1 adapter

[trudenboy]

Hi @Rowr21, glad you're enjoying it! 🙏 Good questions — let me untangle them.

🎯 On sync in general

One important thing to clarify: multiroom sync itself isn't handled by this bridge — it's done by the Sendspin protocol underneath. The bridge just presents each BT speaker as a Sendspin player; the actual clock alignment between group members happens by Sendspin.

What that means in practice: the per-speaker delay value has to be tuned individually for each speaker, because every BT speaker has its own internal audio-processing latency (DAC, DSP, codec decode).
There's no single "correct" value — it's per-device and you have to find it by ear.

👉 Please upgrade to v2.58.0. It ships a new Sendspin version with significant sync improvements, so tuning should be much easier and more stable than on the release you're on now. After upgrading, reset your offsets and tune each speaker individually.

🎧 Sync vs quality trade-off

That's usually not a sync problem — it's A2DP codec/link stability. Two things help:

• Set prefer_sbc_codec: true. AAC sounds marginally better on paper but is fragile over BT; SBC is much more stable, especially with multiple active links.
• Bump pulse_latency_msec if you hear glitches — start at 500, go to 800 if needed. Higher = more robust, slightly more lag.

🛰️ External (non-BT) Sendspin devices in the same group

Just to make sure I'm answering the right question — do you mean MA-native Sendspin players (phone / desktop running the Sendspin/MA client), or something else? Their sync also runs through the Sendspin
protocol, so after upgrading to v2.58.0 and tuning the per-speaker delays, they should fall in line with the group. If drift persists, share a docker logs snippet around the moment it happens.

🔌 Multi-adapter — yes, strongly recommended for 3+ speakers

You're not imagining it. Classic Bluetooth A2DP is time-slotted; the controller has to time-share across every active connection. Most USB BT dongles are solid for 1–2 concurrent A2DP
streams but start showing drops, codec renegotiation and jitter at 3+. It's a hardware ceiling, not something the bridge can fix.

Recommendation: one adapter per 1–2 speakers. We keep a doc with specific adapter recommendations (chipsets, what works well, what to avoid) here:
👉 https://trudenboy.github.io/sendspin-bt-bridge/bluetooth-adapters/

v2.58.0 made all the multi-adapter flows (Add & Pair, Reset & Reconnect, BT Info, Remove) fully adapter-aware, so managing two adapters from the UI is seamless

[Rowr21]

Thanks for the response. I am currently running 2.8.5 for music assistant and 2.59.1 for sendspin BT bridge.

I have set to SBC too. Sync seems to not be working well within the bridge, if I set delay on 1 device to 350, one device is ahead, then at 400 the other is WAY behind, this doesnt make much sense to me with such a small change? Now after changing song, the delay between them is over 1000ms by ear. It's almost like it loses my manual sync when I change track (at this point it was set to 900ms difference betweent he speakers)

And then with other sendspin devices added to the same group, not so good. For example a home assistant voice PE. There doesnt seem to be a way to add any delay to the non-bridge devices in Music assistant?

The BT adapter guide is very helpful! Thank you!

[Rowr21]

With regards to multiroom sync, how close do they need to be manually tuned?

[Rowr21]

2026-04-18 15:05:55,068 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Audio stream configured: codec=flac, sample_rate=44100, channels=2, bit_depth=16, blocksize=2048, latency=high, output_latency=92.9 ms, device=1

2026-04-18 15:05:55,069 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Initialized FLAC decoder for 44100Hz/16-bit/2ch

2026-04-18 15:05:55,070 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:05:55,100 - __main__ - INFO - [Bedroom @ nc28/proc] Audio stream configured: codec=flac, sample_rate=44100, channels=2, bit_depth=16, blocksize=2048, latency=high, output_latency=92.9 ms, device=1

2026-04-18 15:05:55,101 - __main__ - INFO - [Bedroom @ nc28/proc] Initialized FLAC decoder for 44100Hz/16-bit/2ch

2026-04-18 15:05:55,102 - __main__ - INFO - [Bedroom @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:05:55,109 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Sync error 502.2 ms too large; scheduling reanchor

2026-04-18 15:05:55,128 - __main__ - INFO - [Bedroom @ nc28/proc] Sync error 504.8 ms too large; scheduling [reanchor]([url]([_sendspin-client_logs (1).txt](https://github.com/user-attachments/files/26855870/_sendspin-client_logs.1.txt)))

2026-04-18 15:05:55,330 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] [STR-DN1080 0F48D0 @ nc28] Audio streaming, waiting 1.5s for stabilization

2026-04-18 15:05:55,349 - __main__ - INFO - [Bedroom @ nc28/proc] [Bedroom @ nc28] Audio streaming, waiting 1.5s for stabilization

2026-04-18 15:05:55,365 - services.ma_monitor - INFO - MA: player 'Bedroom @ nc28' stale metadata reconnect skipped after startup because playback began

2026-04-18 15:05:56,844 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] [STR-DN1080 0F48D0 @ nc28] Unmuted sink bluez_output.E8_2A_44_C2_1D_2E.1 (startup complete)

2026-04-18 15:05:56,863 - __main__ - INFO - [Bedroom @ nc28/proc] [Bedroom @ nc28] Unmuted sink bluez_output.8C_A9_6F_17_6E_69.1 (startup complete)

2026-04-18 15:06:15,398 - services.ma_runtime_state - INFO - MA syncgroup cache updated: 2 mapped, 1 total group(s)

2026-04-18 15:06:16,451 - __main__ - INFO - [Bedroom @ nc28/proc] Stream started with codec flac

2026-04-18 15:06:16,452 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Stream started with codec flac

2026-04-18 15:06:16,654 - __main__ - INFO - [Bedroom @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:06:16,655 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:06:16,701 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Sync error 500.8 ms too large; scheduling reanchor

2026-04-18 15:06:45,196 - __main__ - INFO - [Bedroom @ nc28/proc] Stream started with codec flac

2026-04-18 15:06:45,197 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Stream started with codec flac

2026-04-18 15:06:45,398 - __main__ - INFO - [Bedroom @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:06:45,402 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Stream STARTED: 1 chunks, 0.10 seconds buffered

2026-04-18 15:06:45,443 - __main__ - INFO - [Bedroom @ nc28/proc] Sync error 540.5 ms too large; scheduling reanchor

2026-04-18 15:06:45,448 - __main__ - INFO - [STR-DN1080 0F48D0 @ nc28/proc] Sync error 548.0 ms too large; scheduling reanchor

2026-04-18 15:06:45,837 - waitress - INFO - Client disconnected while serving /api/status/stream

[trudenboy]

Thanks @Rowr21, these logs flip the diagnosis.

🔍 What the log actually says

Sync error 502.2 ms too large; scheduling reanchor
Sync error 504.8 ms too large; scheduling reanchor
…
Sync error 548.0 ms too large; scheduling reanchor

That's Sendspin's own group-clock scheduler (not the bridge). Both devices land ~500 ms late at every stream start, so it keeps reanchoring. Two takeaways:

1. Both BT speakers drift by the same amount → between themselves they should actually be aligned. The "one ahead, the other way behind" feel is relative to a third reference — the HA Voice PE, which plays on time.
2. static_delay_ms is not the right knob. It's a one-shot offset passed at client_hello; when real output latency drifts 500 ms mid-stream, no per-device constant fixes it — you're chasing a moving target by ear. That's why 350 → "ahead" and 400 → "way behind" feels arbitrary.

💡 Why

Sinks bluez_output.*.1 → PipeWire. It reports output_latency=92.9 ms, but real playout through pipewire-pulse → PipeWire → BlueZ A2DP on Ubuntu/Debian is typically 400–700 ms at default quantum — exactly the gap we see. Streams are also being restarted every 20–30 s, so reanchor never fully settles.

🛠 Two quick things to try

1. prefer_sbc_codec: true — AAC under PipeWire adds buffering.
2. pulse_latency_msec: 800 — counterintuitive, but gives the scheduler room for reanchor to converge.

Restart the container after changing either. Once Sync error … too large stops firing on every start, static_delay_ms becomes meaningful — and you'll need < 50 ms of residual, not 350–400.

📬 Easiest next step — hit Report

In the bridge web UI there's a Report button in the header (⚠ icon next to the version). It auto-packages logs, your config.json (secrets redacted), versions, audio stack, and BT adapter state, and opens a GitHub issue with everything attached.

Click it during a session where the drift is audible so the capture contains the reanchor cycle, not an idle moment. Drop the issue link here and I'll take it from there.