New WASAPI implementation
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- rust
调研方向
Read the existing WASAPI host and the proposed approach in PR #1413, then compare the migration plan with the feature-gated host addition in issue #1299. The issue proposes using WinRT and the wasapi-rs crate, but leaves design and implementation scope open; done means the new implementation works alongside the current host behind a feature before becoming the default.
由索引模型根据 Issue 内容生成。
描述
The WASAPI host could really use a makeover. In particular, switching to WinRT APIs would remove the need to deal with COM, which is quite a headache at times (e.g. #1302, #1402). Further more, it probably makes sense to use the wasapi-rs crate instead of reinventing the wheel, as this would significantly reduce cpal's maintenance burden.
To pick up from https://github.com/RustAudio/cpal/pull/1413#issuecomment-6402800112:
I'm always careful to long for greener pastures. Legacy code has typically accumulated so many fixes and edge cases, that sometimes it's easier to refactor in place than to rewrite entirely.
In general I agree with the sentiment, but in this case I just don't see this approach being viable. The proposed changes will inevitably have to change a lot at once anyway, as switching from raw bindings to a dedicated crate can't really be broken up in small steps, and a similar problem arises with WinRT. If we then add the general code quality concerns of the current implementation on top, we end up with a large amount of extra effort just to find a clean migration path from A to B that remains functional at every step of the way, and I'd much rather spend this effort on making the new implementation as good as possible.
We could approach this the in a similar fashion to #1299, where we start with adding the new host alongside the existing one, guarded behind a feature, and eventually make it the new default.
- 主要语言
- 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 于 3 天前认领。 未关闭host - aaudio platform - android
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复
-
WebAudio wasm build fails with wasm-bindgen panic=unwind closures可能已有人在做 @bogusyogi 于 11 天前认领。 未关闭host - webaudio platform - web
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
host - pipewire platform - linux
难度 4/5 1-2 天 新手友好度 52/100
维护者通常 1 天内回复
-
WASAPI: default-device activation fails with RPC_E_CHANGED_MODE after endpoint-notification callbacks put thread-pool threads into an STA可能已有人在做 @dannyward630 于 4 天前认领。 未关闭correctness host - wasapi platform - windows
难度 4/5 3-5 天 新手友好度 20/100
维护者通常 1 天内回复
-
coreaudio (macOS): capture/playback timestamps double-count the buffer, loopback reads as −2 buffers可能已有人在做 @Marco-Farruggio 于 14 天前认领。 未关闭correctness host - coreaudio platform - macos
难度 4/5 3-5 天 新手友好度 53/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
FalkorDB/FalkorDB#3597 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
needs triage
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 72/100
mozilla-services/syncstorage-rs#2715 ·
维护者通常 1 天内回复