macOS unusual high number of Idle Wakeups in Activity Monitor

[mailinglists35]

macOS Sequoia on Air m1

[mailinglists35]

this is while playing a random radio stream from Radio Browser api

[zaps166]

Is the UI hidden (Window->Hide) during measurements?

[mailinglists35]

it does not seem to influence - numbers are the same regardless if the window is hidden or showing

[mailinglists35]

also, it does seem to happen only while actively playing.

[zaps166]

also, it does seem to happen only while actively playing.

yes, it does nothing when playback is stopped

it does not seem to influence - numbers are the same regardless if the window is hidden or showing

strange, UI refreshing (labels, sliders, text areas and possibly visualizations) costs more than audio playback and it's even more strange that hiding UI doesn't improve energy

do you have audio resampling or equalizer or any effects enabled?

[mailinglists35]

do you have audio resampling or equalizer or any effects enabled?

none, all defaults

[zaps166]

Close visualizations and check if it helps a bit - we have to know if it's UI refreshing issue (even if UI is invisible).

[mailinglists35]

I don't use visualizations - I didn't even know the app has visualizations!

[zaps166]

It means, the UI doesn't drain power (no Visualizations, seek-bar is not used for live streams, only a few small labels). Also it's not decryption (it's pure HTTP).

It can be audio resampling somewhere, unoptimized AAC decoder for ARM, demuxing, buffering, PortAudio library itself... I don't know without debugging (mostly I have access only to macOS virtual machine without good audio support).

@RJVB Did you notice higher power consumption than other players on macOS?

[RJVB]

On Sunday May 17 2026 06:08:39 Błażej Szczygieł wrote: @RJVB Did you notice higher power consumption than other players on macOS?

I never looked at that in particular, but in terms of CPU utilisation I can see only a tiny amount of overhead compared to VLC. Inevitable I think, given that VLC uses its own native implementations and QMPlay2 uses Qt and PortAudio.

[zaps166]

On Sunday May 17 2026 06:08:39 Błażej Szczygieł wrote:
@RJVB Did you notice higher power consumption than other players on macOS?
I never looked at that in particular, but in terms of CPU utilisation I can see only a tiny amount of overhead compared to VLC. Inevitable I think, given that VLC uses its own native implementations and QMPlay2 uses Qt and PortAudio.

Ok, Qt should not add any overhead if UI is not used (event loop is optimized there). So it's most likely PortAudio or my code (including inefficient Qt usage) or resampling or my ARM build is not using assembly optimizations for codecs in FFmpeg.

Generally hard to say without debugging. But you compared to VLC. Curious VLC vs Cuterdio for example. Maybe cuterdio has larger buffers or use more hardware solutions than CPU-only solution (audio decoding, etc.)?

[zaps166]

@mailinglists35 Does it lower power consumption if you go to "Modules settings->PortAudio", increase latencies and apply?

[mailinglists35]

I have changed it to maximum allowed 1 second, but it made no difference.
I am not observing significant power draw (ironically cli mpv is impacting more), it's more on the side of not allowing the cpu to stay in lower frequencies longer.

[mailinglists35]

for the reference they'all playing at same time same url, http://stream.antenne.de/80er-kulthits.aac
I have not tested other codec types.

[mailinglists35]

an interesting surprise comes from Brave browser, overtaking any dedicated player app!