Reviewing and deciding upon a default buffer size strategy for ALSA
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- rust
调研方向
Read the prior discussion linked from the issue, especially the cited comments in pull request #401, to understand the proposed ALSA buffer and period sizing strategies. Then locate the ALSA BufferSize::Default handling in cpal and compare it with the issue’s suggested approach; done means the project has agreed on a suitable default strategy for ALSA.
由索引模型根据 Issue 内容生成。
描述
#401 finally allows users to specify a fixed buffer size, allowing some control over the trade-off between energy efficiency and low latency.
The BufferSize::Default value allows the user to fallback to whatever the default buffer is provided by the host. However, ALSA is a bit of a special case in that the default size can be extreme, sometimes implying a delay from multiple seconds up to a minute - an impractical delay for the majority of applications. As a temporary workaround, #401 has opted to leave the BufferSize::Default branch to select a ~100ms delay to match what was previously hard-coded. I've opened this issue so that we can discuss a more suitable default strategy for ALSA.
See here and here for prior discussion on potential strategies. Of note, @sniperrifle2004 made the following suggestion:
As an alternative suggestion to the lowish 100ms aplay does this by default: Get the maximum buffer time. Cap it at half a second. Then restrict the period time to near a quarter of this buffer time (It's where I got that metric from. aplay has been immensely useful as both a reference implementation and a tool) and then restrict the buffer time to near the chosen value.
- 主要语言
- Rust
- 星标
- 4k
- 派生
- 554
- 平均合并
- 3 天 3 小时
- 30 天内合并 PR
- 4
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
RustAudio/cpal 的其他 Issue
-
aaudio: dynamic buffer tuning never grows the buffer (set_buffer_size_in_frames reports Err on success)可能已有人在做 @dannyward630 于 8 天前认领。 未关闭host - aaudio platform - android
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
WebAudio wasm build fails with wasm-bindgen panic=unwind closures可能已有人在做 @bogusyogi 于 16 天前认领。 未关闭host - webaudio platform - web
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
Load libasound at runtime, or make the ALSA host optional, so Linux binaries don't require libasound未关闭
难度 5/5 一周以上 新手友好度 14/100
维护者通常 1 天内回复
-
API design correctness
难度 4/5 3-5 天 新手友好度 30/100
维护者通常 1 天内回复
-
New WASAPI implementation可能已有人在做 @LastExceed 今天认领。 未关闭code quality dependencies host - wasapi platform - windows
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 2 天内回复
-
Android visitors are offered the Linux .deb on cap.so's homepage and download page可能已有人在做 @patrickballard 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
CapSoftware/Cap#3677 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
DioxusLabs/blitz#1371 ·
维护者通常 1 天内回复