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

Aberta
  • Algo errado?
#97 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
cpp
Domínio
cli

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
C++
Estrelas
18
Forks
7
Merge médio
1d 12h
PRs com merge (30d)
26

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Sendspin/sendspin-cpp-cli

Todas as issues de Sendspin/sendspin-cpp-cli

Issues semelhantes

Mais issues de C++

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.