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

Đang mở
  • Có gì không ổn?
#97 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
cpp
Lĩnh vực
cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C++
Star
14
Fork
5
Merge trung bình
1 ngày 12 giờ
Pull request đã merge (30 ngày)
26

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Sendspin/sendspin-cpp-cli

Tất cả issue của Sendspin/sendspin-cpp-cli

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.