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

Offen
  • Stimmt etwas nicht?
#97 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
cpp
Bereich
cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
C++
Sterne
18
Forks
7
Ø Merge
1 T. 12 Std.
Gemergte PRs (30 T.)
26

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Sendspin/sendspin-cpp-cli

Alle Issues in Sendspin/sendspin-cpp-cli

Ähnliche Issues

Weitere Issues zu C++

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.