Opt wiremix's capture streams out of wireplumber state persistence - #64
Open
HoneyHazard wants to merge 1 commit into
Open
Opt wiremix's capture streams out of wireplumber state persistence#64HoneyHazard wants to merge 1 commit into
HoneyHazard wants to merge 1 commit into
Conversation
wireplumber's state-stream.lua persists volume/mute/target to disk (~/.local/state/wireplumber/stream-properties, write+fsync+rename, debounced) for any node whose media.class matches "Stream/*" - which is what a pw_stream gets by default when no media.class is set, exactly wiremix's capture streams (wirehose/stream.rs::capture_node). These streams are purely internal metering taps with no volume/mute/target of their own worth remembering across launches, so every Props update on one is wasted disk I/O and wireplumber policy work. state-stream.lua already supports a per-node opt-out, checked before any of that work happens: stream_props["state.restore-props"] and ["state.restore-target"]. Setting both to "false" on the capture stream skips it entirely. Confirmed via strace that wireplumber's state-file write path is real and not free, but on investigation the dominant cost on a real system turned out to be an unrelated background process (a stabilizer tone generator repeatedly recreating its own stream) rather than wiremix's captures specifically - so this is a legitimate, low-risk correctness fix (an internal tap shouldn't be treated like a real user stream) more than a load-bearing performance fix on its own. Still worth doing: it costs nothing for any wiremix build, and removes real per-event disk I/O that has no reason to happen for these streams. Tested: cargo test (144/144), cargo fmt --check / cargo clippy -- -D warnings / cargo doc (matching wiremix's CI) all clean.
HoneyHazard
marked this pull request as ready for review
August 9, 2026 05:48
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
That being said, I hope these can be helpful and useful additions that users could appreciate.
wireplumber's
state-stream.luapersists volume/mute/target to disk (~/.local/state/wireplumber/stream-properties, write+fsync+rename, debounced) for any node whosemedia.classmatchesStream/*- which is what apw_streamgets by default when nomedia.classis set, exactly wiremix's capture streams (wirehose/stream.rs::capture_node). These streams are purely internal metering taps with no volume/mute/target of their own worth remembering across launches, so every Props update on one is wasted disk I/O and wireplumber policy work.state-stream.luaalready supports a per-node opt-out, checked before any of that work happens:stream_props["state.restore-props"]and["state.restore-target"]. Setting both to"false"on the capture stream skips it entirely.A note on scope, in the interest of not overselling this: I confirmed via
stracethat wireplumber's state-file write path is real and not free, but on investigation the dominant cost on a real system with many concurrent streams turned out to be an unrelated background process (something else entirely was recreating its own stream repeatedly) rather than wiremix's captures specifically. So this is a legitimate, low-risk correctness fix - an internal tap shouldn't be treated like a real user stream - more than a load-bearing performance fix on its own. Still worth doing: it costs nothing for any wiremix build, and removes real per-event disk I/O that has no reason to happen for these streams.Tested:
cargo test: 144/144 passingcargo fmt --check/cargo clippy -- -D warnings/cargo doc(matching this repo's CI): all cleanDrafted with AI assistance (Claude); reviewed by me before opening. Left as a draft while I finish going through it - not requesting review yet.