Skip to content

Persistently track frames of silence for inactivity timeout - #23

Closed
edwloef wants to merge 1 commit into
httpsworldview:mainfrom
edwloef:fix-max-silence-seconds
Closed

Persistently track frames of silence for inactivity timeout#23
edwloef wants to merge 1 commit into
httpsworldview:mainfrom
edwloef:fix-max-silence-seconds

Conversation

@edwloef

@edwloef edwloef commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Summary

If I understood correctly, the tracking of silent frames up to MAX_SILENCE_SECONDS was supposed to serve as a kind of inactivity timeout. However, this previously only took one single update into account, instead of accumulating across multiple updates. The new test should clarify what I mean.

Fixing this reduced idle CPU usage by about 30%, but also made apparent that the previous threshold of 2 seconds was too low, so I increased it to 10 seconds.

Related issues

Closes #

Checklist

  • I read CONTRIBUTING.md.
  • Commits include a Signed-off-by: footer.
  • I added or updated tests, or explained why not.
  • I updated documentation when user-visible behavior changed.
  • If AI tools were used, I reviewed the result carefully.

Signed-off-by: edwloef <edwin.frank.loeffler@gmail.com>
@httpsworldview

Copy link
Copy Markdown
Owner

Thank you for the investigation and for identifying the idle CPU cost. Still, I don't know that we should make the silence limit cumulative. That existing 2 second check is a replay bound for a single large timeline gap. Somewhat regrettably, visuals are designed to need zero samples so histories scroll out and meters decay normally. Calling the reset function after a fixed timeout abruptly clears states; ten seconds also cannot account for visual size, scroll speeds, or other configurations.

implementing this at the present would require processor specific fast-paths for zero valued pcm (similar to what the spectrogram has) or a way for visuals to individually report that they are actually quiescent. the end result of how things are done now is some unnecessary processing, but I still think it's fine.

If that idle CPU usage proves to be unacceptable, I will take time to handle it in another way. for now, I am going to close this PR. Thank you so much either way!

@edwloef

edwloef commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

processor specific fast-paths for zero valued pcm (similar to what the spectrogram has)

That's interesting to hear, since the spectrogram is still the slowest block to process silence. Here's how it breaks down on my computer:
image

I'm interested in idle CPU usage because I'd like to be able to use openmeters on my laptop without needing to worry about battery drain (and without needing to constantly open and close the program, since that's a bit inconvenient in bar mode). Right now it consumes about 20% of one core in my laptop's power-save mode, in an ideal world that'd be closer to about 10%.

@httpsworldview

Copy link
Copy Markdown
Owner

That flamegraph seems to show the spectrum analyzer being the most expensive, not the spectrogram. SpectrogramProcessor tracks audio_last_nonzero while buffering PCM, and if the buffered audio is entirely zero, process_ready_windows() skips straight to emitting an empty reassigned column or a classic column filled at DB_FLOOR. the shader then skips those, so next to no work is done. I never gave the other visuals similar logic, which explains why they are now the heaviest during silence.

Regardless, I hear you, and I'll work on adding some logic for the rest of the visuals to cut down on idle CPU usage. I'll reference this PR in future commits.

@edwloef

edwloef commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

Oops, sorry for the mixup :P

@httpsworldview

httpsworldview commented Aug 11, 2026

Copy link
Copy Markdown
Owner

No problem! Also, I just remembered that in the meantime you can just pause OpenMeters with p if you want to keep it open while nothing is happening. Pausing stops the rendering loop and all audio ingestion, so CPU should drop to ~0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants