0.4.0 (sendspin-cpp v0.9.5): Lost sync every 10 s on Raspberry Pi 3B while host clocks slew — please release with sendspin-cpp#208

Aperta
  • Qualcosa non va?
#97 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
cpp
Ambito
cli

Direzione di ricerca

Start by reading Sendspin/sendspin-cpp#208, which the report identifies as the relevant clock fix, then inspect how this CLI project selects and releases its sendspin-cpp dependency. Confirm whether the release build includes that change; done means a CLI release with the fix that the reporter can retest on the same hardware.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

On two Raspberry Pi 3B players, sendspin-cli 0.4.0 (sendspin-cpp v0.9.5) logs Lost sync many times a minute, and each correction is an audible dropout. Most corrections are about 5 ms, and a larger one (50–100 ms) comes every 10 s exactly. The pattern does not depend on the output backend, the buffer size or the DAC. On the same Pis, with the same server and the same streams, the Python reference client (sendspin 8.0.0) plays cleanly.

The trigger looks like the one Sendspin/sendspin-cpp#208 describes: the hosts' clocks were being slewed hard by their time daemons. #208 was merged on 2026-10-17, after v0.9.5 (2026-10-14) and after cli v0.4.0 (2026-10-15), so this build does not have it. Could a cli release with sendspin-cpp ≥ #208 be cut? I'm happy to retest it on the same hardware.

Setup
Player hardware Raspberry Pi 3B Rev 1.2, Raspberry Pi OS Trixie arm64, kernel 6.18 (rpt)
Outputs tested HiFiBerry Digi2 Pro (WM8804, S/PDIF), HiFiBerry DAC2 HD (PCM1796); a second Pi with an Amp3 has the same software
Player sendspin-cli 0.4.0, sendspin-cpp v0.9.5, release binary
Server Music Assistant 2.10.7 (aiosendspin) on an x86 host on the same wired LAN
Network Wired, ping 0.5 ms average, no loss, under 3 ms max over 150 pings
Load on the Pi ~0.5 % CPU, no throttling (get_throttled=0x0), ~47 °C

What the log shows

At 96 kHz, 250 ms buffer, Digi2 Pro, ALSA hw: output: 77 Lost sync in about 5 minutes, in two groups:

W sendspin.sync_task: Lost sync (5139us off)
W sendspin.sync_task: Lost sync (5115us off)
W sendspin.sync_task: Lost sync (5021us off)
W sendspin.sync_task: Lost sync (78618us off)    <- every 10 s
W sendspin.sync_task: Lost sync (5005us off)
...
W sendspin.sync_task: Lost sync (78360us off)    <- 10.0 s later
...
W sendspin.sync_task: Lost sync (69714us off)    <- 10.0 s later

Each one is followed by Regained sync almost at once. No underruns are logged.

What changed and what didn't

Change Result
96 kHz → 48 kHz Fewer small corrections; the ~90 ms ones every 10 s remain
buffer-ms 250 → 100 Worse: a ~5 ms correction about every second, plus a ~50 ms one every 10 s. The large offset scales with the buffer (~50 ms at 100, ~80–90 ms at 250)
ALSA hw: → -o portaudio Fewer small corrections; the 10 s ones remain
Digi2 Pro → DAC2 HD (different card, own clock oscillators) No change
Python sendspin 8.0.0 on the same Pi, card, server and stream (PortAudio) Clean, by ear over several tracks

Measured from /proc/asound/.../status over 20–60 s, the card's hw_ptr advanced 0.14–0.45 % slower than nominal, and the figure varied between windows. That looks like output restarts or pauses from the corrections, not a slow crystal.

The clock situation (likely trigger)

While this happened:

  • the server host's systemd-timesyncd was pinned at +500 ppm (max slew), with the clock 314 ms behind its source and stepped back 15 times in 3 days;
  • the Pi's timesyncd reported 0.9 s offset with 677 ms jitter.

The LAN's NTP source (a router) had an unstable clock. With chrony on both machines and internet time sources, the clocks are now steady, but the cpp player still showed the 10 s corrections (chrony was still slewing out a few hundred ms at the time). The Python client uses aiosendspin, which timestamps on CLOCK_MONOTONIC_RAW. That would explain why it was unaffected, and it matches #208's description.

Possibly related: #32 (continuous Lost sync on -o pulse, no underruns).

Config used

name = <player>
output = hw:CARD=sndrpihifiberry,DEV=0   # also tried: portaudio
buffer-ms = 250                            # also tried: 100
fixed-volume = true

Happy to provide full logs, or to test a pre-release build.

Lingua principale
C++
Stelle
14
Fork
5
Merge medio
1g 12h
PR unite (30g)
26

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Sendspin/sendspin-cpp-cli

Tutte le issue di Sendspin/sendspin-cpp-cli

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.