Recovering from a device outage reports a sync error and plays silence for the swallowed lookahead
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- cpp
- 领域
- audio-video-rtc, cli
调研方向
Start by reading the existing write() deadline and wait-slice behavior, then trace SyncTask::process_playback_progress during device recovery. Compare the four sink implementations and the mentioned sendspin-cpp alignment API before choosing an approach. Done requires an agreed recovery behavior that avoids the reported error and long silence, with scope confirmed for all affected sinks.
由索引模型根据 Issue 内容生成。
描述
Split off from #55, which fixes the #54 playback-clock bug for ALSA. The recovery is correct and bounded now, but it still costs one sync error and a long silence.
What happens
Measured on #55's hardware test, a 14 s USB DAC replug at 48 kHz:
- While the device is absent,
write()swallows audio immediately. Nothing back-pressures the sync task, so it drains its decode pipeline and keeps feeding whatever arrives. The stream pointer ends up ahead of real time by the server's send-ahead. - At reopen, the retired outage gap resets the playtime estimate to the device's finish timestamp (
SyncTask::process_playback_progress). The playhead is correct from here on. - The next chunk is not due for about 10.8 s, far past the 5 ms
HARD_SYNC_THRESHOLD_US, so the sync task reports ERROR once (Lost sync (10840302us off)) and inserts silence until the timeline catches up. Sync is regained roughly 11 s later.
So it is one bounded event rather than the loop #54 reported, but an operator still sees an ERROR state and about 11 s of silence after every recovery.
Two ways to avoid it
1. Pace the discard (this repo). While the device is absent, consume audio at roughly real time — waiting out write()'s existing deadline rather than returning at once — so the pipeline keeps its lookahead and the stream pointer stays near real time. The correction at reopen then lands inside the soft-sync range and nothing reports an error. write() already has a deadline and waits in slices, so the shape is there. The risks are a sink that blocks longer than the player expects during an outage, and that it should apply to all four sinks (#58).
2. Signal the outage to the library (needs sendspin-cpp). The sync task already suppresses the ERROR state while aligning, for initial sync and post-seek alignment. A sink that reported "I lost the device and have retired the gap" could get one silent realignment instead of an ERROR/SYNCHRONIZED pair. That needs an upstream API, so it would carry Requires-Upstream.
Option 1 shortens the silence as well as removing the error; option 2 only relabels it. Worth deciding which behaviour is wanted before implementing either.
- 主要语言
- C++
- 星标
- 3
- 派生
- 3
- 平均合并
- 5 小时 26 分钟
- 30 天内合并 PR
- 35
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Sendspin/sendspin-cpp-cli 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 78/100
Sendspin/sendspin-cpp-cli#70 · 2 条评论 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 45/100
Sendspin/sendspin-cpp-cli#32 · 1 条评论 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 38/100
Sendspin/sendspin-cpp-cli#30 · 3 条评论 ·
维护者通常 1 天内回复
查看 Sendspin/sendspin-cpp-cli 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
KhronosGroup/Vulkan-Tutorial#524 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
microsoft/onnxruntime-genai#2633 ·
维护者通常 1 天内回复
-
mapper bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 86/100
firebase/firebase-ios-sdk#16718 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 88/100
tesseract-ocr/tesseract#4627 ·