mic capture: ring buffer overflows almost immediately once capture starts — game may not be draining MicRead
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- audio-video-rtc
Research direction
Start with src/runtime/patch/mic_provider.cpp, especially the ring capacity and overflow handling, then trace how CaptureAndEncodeLocalVoice is gated in the game. Determine whether a quiet reader is expected in the affected modes and how stale buffered audio should be handled; the issue is resolved when capture delivery behavior is understood and the fast overflows are addressed or explained.
Written by the indexing model from the issue text.
Description
Found during review of PR #90 (#51).
In 15 of 22 captured client runs where mic capture actually started, "ring buffer full — game is not draining MicRead" followed — in 13 of those 15 within 0.54-0.93s of "capture started" (two took ~10s and ~60s). The ring buffer holds 500ms (kRingCapacitySamples = 24000 at 48kHz, src/runtime/patch/mic_provider.cpp:66), so the game is reading at most ~40% of real-time audio in that window, and nearly nothing in the fast-overflow runs.
The game's reader (CaptureAndEncodeLocalVoice, 0x140d7bd90 per ReVault) only runs under certain modes (gated on offset 0x8c14 and a per-slot bit) — a quiet reader may be expected in some of those sessions, but this is unresolved. Even once the game does read, it first gets up to 500ms of stale audio from the ring.
This is separate from #51 (which was specifically the thread-ownership rejection preventing capture from starting at all, fixed in PR #90) — #51's fix makes capture start reliably, but doesn't address whether captured audio is actually delivered to the game once it does.
- Dominant language
- C++
- Stars
- 2
- Forks
- 3
- Avg merge
- 9h 6m
- Merged PRs (30d)
- 459
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from EchoTools/nevr-runtime
-
backlog
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
EchoTools/nevr-runtime#957 ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
EchoTools/nevr-runtime#892 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
EchoTools/nevr-runtime#889 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
EchoTools/nevr-runtime#801 · 1 comment ·
Maintainers usually reply within 1 day
-
backlog
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
EchoTools/nevr-runtime#796 ·
Maintainers usually reply within 1 day
All issues in EchoTools/nevr-runtime
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 9 days
-
自定义颜色添加为常用颜色Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
mg-chao/snow-apps#2227 · 2 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
pnnx Python convert ignores fp16=False with input_shapesPossibly taken @ktz03 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Tencent/ncnn#7183 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day