Output pipeline lag monitoring
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 12/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 冷清
- 技术栈
- audio-video-rtc, rust
调研方向
The issue asks for a rodio API for output pipeline lag, built from CPAL's device-playback timestamps, but it does not settle the shape of that API. Start by reading how rodio's output stream wraps CPAL's output callback and the timestamp data that callback receives. Done means a design decision agreed with maintainers, since the author explicitly leaves the API surface open and it links to issue 597 for context.
由索引模型根据 Issue 内容生成。
描述
For real-time applications performing voice conversation, it can be important to know the output pipeline's lag, case in point being wanting to not listen to their own audio output if they don't use an algorithm for detecting own-output on the real-time audio input stream while playing output.
The underlying information signal for this is already available from CPAL but currently not being used by rodio code; hence there is neither any rodio API surface for querying it.
How API surface exposing those timestamps from CPAL or API surface providing digests of them would likely be highly opinionated. My own patch for that information is Generative AI based and does not reflect a generic sense of what different scenarios than my own would want the API surface of it to be like:
- It's not a raw raw-timestamp passthrough API passing the timestamps from rodio,
- But one which provides a digest of accumulates stats when called.
- For every CPAL output callback, it subtracts the callback invocation timestamp from CPAL’s predicted device-playback timestamp, and keeps these as samples on a ring-buffer.
Which is highly opinionated.
It would be nice to have an equivalent catering to the overall desire for lag information based on CPAL's said timestamps, which closely fits the realtime considerations and preferences of this project about timing-related telemetery API.
Related
- 主要语言
- Rust
- 星标
- 2.5k
- 派生
- 338
- 平均合并
- 1 天 3 小时
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
RustAudio/rodio 的其他 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 74/100
-
难度 1/5 1 小时以内 新手友好度 73/100
-
难度 3/5 1-2 天 新手友好度 62/100
-
WavDecoder::size_hint underflows (u32 wrap, ~4.29e9) after EOF, causes multi-GB Vec::collect() allocation可能已有人在做 @marin-m 于 3 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
-
难度 4/5 3-5 天 新手友好度 45/100
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
area/desktop-shell P1-high
难度 2/5 1-3 小时 新手友好度 76/100
yantrikos/yantrik-os#998 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
warpdotdev/warp#16662 ·
维护者通常 1 天内回复
-
bug P2
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复