Idle CPU: a fixed 10 ms main loop, and a PulseAudio stream that stays open after the stream ends
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- cpp, linux
- Lĩnh vực
- audio-video-rtc, performance
Hướng nghiên cứu
Start with the fixed sleep in the main loop: LOOP_INTERVAL_MS at src/main.cpp:57 and the sleep_for block at src/main.cpp:733-743. The PulseAudio cork/close fix belongs in the code that handles the stream-ended event, which the payload does not name, so locate it first. Run the player with -o pulse, go idle after a stream ends, and confirm with pactl that the sink input is corked and the sink suspends. Done means both idle wakeup rates drop and the sink suspends, but the loop change may need the library to expose a waitable fd first.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
An idle player has a CPU floor that never drops, and a stream that has ended keeps the sound server busy too. Neither is large, but both show up in "why does an idle player use CPU at all" reports. Downstream: music-assistant/local-audio-addon#31, where an idle player used about three times what the Music Assistant server did.
Measured on v0.3.0 (sendspin-cpp v0.8.0), -o pulse into Home Assistant OS's PulseAudio, x86_64, 4 cores.
1. The main loop polls every 10 ms, idle or not
src/main.cpp:57 sets LOOP_INTERVAL_MS = 10. Every pass polls mDNS, the control socket, the network provider, the sink and the hooks, then does sleep_for(10ms) (main.cpp:733-743), whether or not anything is happening.
| Thread | Wakeups/s | CPU |
|---|---|---|
main (sendspin-cli) |
98 | ~0.9% of one core, idle after a stream |
That is the whole idle floor of the process. A loop that blocks on its file descriptors (the control socket, the mDNS fd, the websocket) with a timeout set by the next due timer would bring an idle player close to zero wakeups. The catch is that sendspin-cpp's network provider is polled from this loop (network provider polled only from the main loop in the v0.9.5 notes), so the library would need to expose something to wait on.
2. The native PulseAudio stream is never corked or closed when a stream ends
After I player: Stream ended, with status reporting state: paused and stream: idle, the PulseAudio sink input stays connected and uncorked:
Sink Input #3
Sink: 0
Corked: no
application.name = "sendspin-cli"
0 alsa_output.pci-0000_00_1f.3.analog-stereo ... RUNNING
The result:
- libpulse's I/O thread (
threaded-ml) keeps waking about 97 times a second. - The server's sink stays
RUNNINGand never suspends. The PulseAudio daemon itself sat at 1.6% of a core, almost all in its ALSA sink thread. - Any USB DAC or amp behind the sink is held awake, and module-suspend-on-idle never gets the chance to act.
Corking the stream at stream end (and uncorking at the next start), or closing it, would let the sink suspend. I haven't checked whether the ALSA, PipeWire or PortAudio sinks hold their device the same way.
How it was measured
Per-thread utime+stime deltas from /proc/<pid>/task/*/stat over 10-20 s windows, and voluntary plus nonvoluntary context-switch deltas from /proc/<pid>/task/*/status for the wakeup rates. Sink state is from pactl list sink-inputs and pactl list short sinks inside the Home Assistant audio container.
- Ngôn ngữ chính
- C++
- Star
- 18
- Fork
- 7
- 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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Sendspin/sendspin-cpp-cli
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Sendspin/sendspin-cpp-cli#111 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Feature request: keep the ALSA output running briefly between streams (--keep-output-alive <s>)Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
Sendspin/sendspin-cpp-cli#109 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
Sendspin/sendspin-cpp-cli#108 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
Sendspin/sendspin-cpp-cli#106 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
Sendspin/sendspin-cpp-cli#97 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Sendspin/sendspin-cpp-cli
Issue tương tự
-
Linux npm packaging leaves workspace files that block subsequent CI checkoutCó thể đã có người làm @Spockkk0225 đã nhận hôm nay. Đang mởci
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
alibaba/neug#1195 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 3 ngày
-
QA/No release-notes/exclude tests tests/missing-coverage tests/test-quality
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 71/100
brave/brave-browser#61019 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
? - Needs Triage bug CUTLASS C++
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 4 ngày