Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Heavy CPU use with HDMI LocalUI, normal?
#1
One of my Moode boxes lives under my TV,  with its "dac" being my HT amp.   I hook it up to the amp, via HDMI.  The amp even has an input default labled "streaming box".   All good... and when I turn on the localUI switch,  I even get the Mood UI showing up on the TV.  Great.

The thing I noticed recently, is that the CPU usage on the Pi,  is very high when the display is on and audio playing.  Like, really high,  like 2.0 usage or more on a Pi 3, and 70-80% CPU.   Is this expected?  I've checked this behavior and it's the same, on 8.1.2 and 8.2.0 boxes.

Done some poking around,  and I've determined that it works something like this:

When the LocalUI switch is on,  and playing something, 7-10 or more chromium browser instances show up, using 70-80% of resources.

When audio stops playing,  instances cut back to 5-7,  and CPU usage goes down to 10-15%

Just audio playing with LocalUI off,  usage is only 5-7%  Basic playing a 320k stream, to 16b/44.1kb/s audio, no SOX or fancy stuff.

I thought I was seeing occasional times where usage stayed in the 70-80% range, even with audio off,  but see below....

If it goes into Screen Blank mode while still playing,  audio stops but usage stays in the 70-80% level like it was when playing

If audio stops before going into Screen Blank mode, usage returns to a 10-15% level.  

There is another switch, something like Enable LocalUI on Play,  that starts the UI if you go to play,  but also, will prevent the screen blank from happening, if the music is on.  This prevents it from cutting off the display after the set timeout if it's playing something.  This should always be used with a HDMI audio setup,  since it prevents the high CPU case but even more importantly,  see below...

If the Screen Blank comes on and the screen is blanked, during play,  without the above Enable on Play switch,  the screen AND audio are cut off. HDMI video AND audio go off.  If Enable LocalUI on Play is on,  the screen and audio stay on, as long as something is playing.

This last thing is a separate bit of annoyance that was discovered while I was shaking this thing down.    Wonder if there's an easy way to have the HDMI video be enabled or disabled separately from the HDMI audio...   or are they unavoidably tied together?

As another comparison,  my other Pi 3 Moode box that proudly sits on top of my Schitt Stack of a Modi 3 and Magni 3,  to Sennheiser HD6xx headphones...  always stays in the 5-8% usage range,  driving the USB Modi3 DAC,  and no LocalUI needed...

Thoughts?
Reply
#2
When it comes to LocalUI the lowest CPU utilization occurs when displaying CoverView with one of the static backdrops for example the Linear Gradient. On one of my systems it's < 10% CPU utilization using moodeutl -m. If I run top and use the "1" option to display the cores it looks lsomethingike below.

Code:
%Cpu0  :  5.8 us,  1.0 sy,  0.0 ni, 93.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  8.1 us,  1.3 sy,  0.0 ni, 90.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  6.0 us,  1.0 sy,  0.0 ni, 93.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  5.7 us,  3.0 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
There is a Prefs setting in the CoverView section named "Automatic display" that can automatically show CoverView on the attached display.
If the main UI with the knobs and Queue is being displayed the lowest CPU utilization happens when the "Now playing" icon is turned off. The setting is in the Playback section of Prefs.
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#3
(09-24-2022, 11:00 AM)Tim Curtis Wrote: When it comes to LocalUI the lowest CPU utilization occurs when displaying CoverView with one of the static backdrops for example the Linear Gradient. On one of my systems it's < 10% CPU utilization using moodeutl -m. If I run top and use the "1" option to display the cores it looks lsomethingike below.

Code:
%Cpu0  :  5.8 us,  1.0 sy,  0.0 ni, 93.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  8.1 us,  1.3 sy,  0.0 ni, 90.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  6.0 us,  1.0 sy,  0.0 ni, 93.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  5.7 us,  3.0 sy,  0.0 ni, 91.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
There is a Prefs setting in the CoverView section named "Automatic display" that can automatically show CoverView on the attached display.
If the main UI with the knobs and Queue is being displayed the lowest CPU utilization happens when the "Now playing" icon is turned off. The setting is in the Playback section of Prefs.
Yeah, I'm talking about the main UI case.  It's quite a large difference when you start playing something.  Was rather surprised at the 70-80%. I imagine it's checking for changes on the volume, play controls, updating screen timers then, so it gets busier,  but,  wow...

I had the TV box go unresponsive, or have no HDMI vid output, or the white screen with "Aw Snap..." occasionally,  started looking into things and saw the browser crashing and OOM'ing in the logs...  that's what got me looking into things. 

Hmmm...  sounds like there's a few options for TV use,  just showing the station or album.  I'll check them out.  Since the control doesn't happen on the TV, (maybe could if I added a kbd and mouse?)  there isn't as much need for the main UI on the TV when I'm controlling things from the phone.  OTOH, it is nice to have a view of playlist/radio stations, and have a bigger or group view of the library on the big screen...

I have a few htop screenshots, documenting various states,  if you're interested.  Not sure I have an active account in a Photobucket like site, to send a linked image, but could work something out.
Reply
#4
Here's a top snapshot of one of my systems that has an attached HDMI display. Its playing a radio station and displaying the main UI with the knobs, queue covers and the now playing icon.

CPU utilization looks reasonable across the 4 cores ~ 25%

Code:
top - 20:17:39 up  2:40,  1 user,  load average: 0.88, 1.07, 0.90
Tasks: 157 total,   1 running, 156 sleeping,   0 stopped,   0 zombie
%Cpu0  : 28.5 us,  3.6 sy,  0.0 ni, 67.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 20.1 us,  5.8 sy,  0.0 ni, 74.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 28.8 us,  4.4 sy,  0.0 ni, 66.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 19.3 us,  3.4 sy,  0.0 ni, 77.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :    909.6 total,    180.4 free,    257.8 used,    471.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    566.0 avail Mem
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#5
(09-25-2022, 12:21 AM)Tim Curtis Wrote: Here's a top snapshot of one of my systems that has an attached HDMI display. Its playing a radio station and displaying the main UI with the knobs, queue covers and the now playing icon.

CPU utilization looks reasonable across the 4 cores ~ 25%

Code:
top - 20:17:39 up  2:40,  1 user,  load average: 0.88, 1.07, 0.90
Tasks: 157 total,   1 running, 156 sleeping,   0 stopped,   0 zombie
%Cpu0  : 28.5 us,  3.6 sy,  0.0 ni, 67.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  : 20.1 us,  5.8 sy,  0.0 ni, 74.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 28.8 us,  4.4 sy,  0.0 ni, 66.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  : 19.3 us,  3.4 sy,  0.0 ni, 77.0 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :    909.6 total,    180.4 free,    257.8 used,    471.4 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    566.0 avail Mem

Those are my conditions, except for using the HDMI as the "DAC",  or more accurately, using the HDMI as a data output to the AV amp DAC, while it displays the screen.  I'm not sure if that makes a difference yet... I do have a monitor I could try.

This is what I get, using plain top -1, like you did:

Code:
top - 20:11:49 up 6 min,  1 user,  load average: 2.05, 1.19, 0.55
Tasks: 162 total,   2 running, 160 sleeping,   0 stopped,   0 zombie
%Cpu0  :  6.8 us,  4.8 sy,  0.0 ni, 88.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st    
%Cpu1  : 17.3 us,  2.3 sy,  0.0 ni, 80.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  : 43.4 us,  3.4 sy,  0.0 ni, 53.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st    
%Cpu3  : 27.6 us,  3.9 sy,  0.0 ni, 68.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    923.5 total,    276.5 free,    201.1 used,    445.9 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.    630.5 avail Mem

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1418 pi        20   0  414180 125804  95224 R  83.5  13.3   1:57.46 chromium-browse
1463 pi        20   0  463428  86960  75928 S  12.5   9.2   0:23.20 chromium-browse
1172 mpd       20   0  204508  31368  22272 S   3.0   3.3   0:03.91 mpd

This is a Pi3, wondering if you have a Pi4, and we're looking at the relative compute power difference. It also looks more drastic in htop, with many more chromium-browse threads visible.  Overall average CPU% per core floats around the hi 20's to 30's on the average.

The odd thing that stands out for me,  is the huge difference between the playing audio and not playing audio cases.  And underlining that, while I was gathering top measurements to respond,  I found my TV Moode box in the "broken display" state again (the blank white screen with the "Aw Snap.." on it)  so I tried to bump it back with the "Restart LocalUI" button, which works,  but it came back at some lower, narrower resolution than the full 1900x1080 it usually puts out.  The interesting thing...  in that resolution and playing music, there was no noticeable increase from not playing... just a fraction of what we're seeing here.  Maybe there's something wrong with the full HD mode, or lower modes are disproportionally much better? Rebooting got it back to 1900x1080... and the above top results when playing.

I'll try to verifiy that, problem is I have to wait till it fails again,  or, how do I change resolutions, in HDMI display mode?

Do'h.. I see a HDMI Resolution thread here... that's a start...
Reply
#6
Which Pi is that, Tim?
Reply
#7
it's a 3B+
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply
#8
(09-28-2022, 05:34 PM)Tim Curtis Wrote: it's a 3B+

Huh... was expecting a 4.  Mine (this one) is a 3B 1.2.   A little less powerful than a 3B+,  which I also have as my other Moode player. 

Odd, that mine seems a bit different (if all the cores average, it might be mid 20's to low 30's%)  and the load average seems so different,  with the CPU usage looking somewhat closer than farther.  Could be length of runtime they've both had. I notice a HUGE load that settles down quickly, when you go from idle to play.  Ii I just reboot it and start doing top numbers,  that might factor in.

I was amazed by the difference between the idle and playing use, though. 80-100% of one core,  vs 18-20% when not playing.   The difference without a localUI  is something like 2-4% idle (probaby half used by top itself) to 4-8% used by MPD  when playing something.  Maybe I've seen 20-30% playing load when doing high settings SOX resampling and playing a 24b radio station.  Wondered if that was normal,  it was so different.

I still haven't had the chance to play with resolutions.  Found the player unresponsive again, dmsg showed more crashing and OOM reaping on the browser.  This time it didn't come back to a lower res,  so no quick experiment...
Reply
#9
I'm seeing the same issue with a similar setup (3B+ 1.3)  It starts stable, but after a while (20-30 min?), chromium-browser-v7 starts consuming memory and after a minute or so all memory is consumed and the system becomes unresponsive.  I have not been able to find anything in the logs that would coincide with the onset of memory consumption.  It doesn't make a difference if music is played or not.  Screen resolution doesn't seem to be a factor either.

I found that several packages were being excluded from updates, including chromium.  I got them to update, but still no joy.  I'm going to keep poking around.

--Mike
Reply
#10
(10-18-2022, 03:44 PM)pfeuffer Wrote: I'm seeing the same issue with a similar setup (3B+ 1.3)  It starts stable, but after a while (20-30 min?), chromium-browser-v7 starts consuming memory and after a minute or so all memory is consumed and the system becomes unresponsive.  I have not been able to find anything in the logs that would coincide with the onset of memory consumption.  It doesn't make a difference if music is played or not.  Screen resolution doesn't seem to be a factor either.

I found that several packages were being excluded from updates, including chromium.  I got them to update, but still no joy.  I'm going to keep poking around.

--Mike

What version of chromium-browser?

Code:
dpkg -l | grep "chromium-browser"
Enjoy the Music!
moodeaudio.org | Mastodon Feed | GitHub
Reply


Forum Jump: