[Merged] Power Saver feature

cyperghost

@Hex I like your build very much.

In ES there is a loop that receives key presses/events.

I guessed that... I already told @pjft and you (??) in this thread. Why is there a loop wating for key events? Triggers to interrupts are a good way avoiding this. So you hunted that nasty workaround down :D

I have a "wish" to the Music Player.... Would it not be better to use mpg123 instead OMX Player? Just for background? The intention is following. OMXPlayer is already used for video playback and video preview. To have an independent process use an independent software just for background. MPG123 gots only 2% CPU usage. The control is just easy and you don't need a python backend.

STOP/PLAY ... even restart can be done by script (or if you develop ES in C++ there are much more options I guess)

Start/Stop Toogle, Start if mpg123 isn't started.sh

#!/bin/bash 
#Toggle MPG123 Music Player to mute/unmute condition
#Simple by checking running PID and sent -STOP or -CONT term
#Is no PID of MPG123 is available it will be launched


command="mpg123"

pids="$( pgrep "$command" )"

if [[ -z "$pids" ]]; then
    "$command" -Z /media/usb0/BGM/*.mp3 >/dev/null 2>&1 &
    exit 0
fi

for pid in $pids; do
    state="$( ps -ostate= -p "$pid" )"

    stopped=0

    case "$state" in
        *T*)    stopped=1 ;;
    esac

    if (( stopped )); then
        kill -s CONT "$pid" >/dev/null 2>&1
#        printf '"%s" (%d) has been unpaused\n' "$command" "$pid"
    else
        kill -s STOP "$pid" >/dev/null 2>&1
#        printf '"%s" (%d) has been paused\n' "$command" "$pid"
    fi
done

The Next Track command is simply
It kills mpg123 and restart it again in random mode ... so you randomly got BGM music. Hey... It's a decent ( @Hex - what the hell is your background song?) background music and not your sisters beloved POP album :D

#!/bin/bash
#This changes track by killing musicplayer
#and reloading it

pkill mpg123 >/dev/null 2>&1
sleep 1
mpg123 -Z /media/usb0/BGM/*.mp3 >/dev/null 2>&1 &

STOP

#!/bin/bash
#This STOPs musicplayer

pkill -STOP mpg123

CONTINUE

#!/bin/bash
#This STOPs musicplayer

pkill -CONT mpg123

Even we can using BGM in gameplay via User Menu

#!/bin/bash
#This STOPs musicplayer

pkill -CONT mpg123; exit 2

Zigurana

@Hex Hi, did you do any power consumption profiling with PS enabled/disabled?
I am wondering how much this actually saves in terms of power consumption.

I think one way to do it would be through one of those usb-power consumption doodaa's, but they might not be precise enough.
In any case, this is very relevant to my interests, with the RaspiBoy coming up soon!

cyperghost

@Zigurana May you test out please?

The CPU usages are triggered in this thread
https://retropie.org.uk/forum/topic/11178/emulationstation-cpu-usage

It's a the STANDARD ES for RetroPie 4.2
We ( @Sano and me) used top for CPU usage measurement

Sano

@cyperghost
I also used pidstat (part of sysstat package) that monitors the CPU usage of a single PID :)
@Zigurana
you may try powerstat or powertop

Hex

@cyperghost I wrote the server in 2012 when Raspberry pi 1 was released. I had the source code and it was well designed enough that it didnt take long for me to write an interface. The best feature is that all control requests silently fail if backend is not running. The Music player is very advanced with a websockets server support already coded into the backend thus if a day comes to incorporate a full fledged MusicPlayer it would be a breeze.

Hex

@Zigurana I dont have the USB doctor device so I cannot test it. Someone else can if they have one.

cyperghost

@Hex Sorry I missed your post!
Yes the phython backend works surely fine but it is a script that has to be configurated. That's my main misgiving or may I am wrong? I think easy access can be givento users by a standarized playlist location and in this playlist all songs from different locations can be stored...

Sorry for being inconvinient :)

About your PR... can you give us a compiles binary please?

Hex

@cyperghost I shall provide binaries for Pi 1/Zero only. Pi3 is fast enough to compile in 10 mins and I dont have an sdcard for it :(

There is no configuration needed. Plays audio from all files including videos downloaded from youtube. It can be controlled from android app too if needed (needs extended version).
On the backend it uses Aplay and avconv which are both available on the raspbian/retropie

Hex

Pi zero/1 binary is now available. It has two modifications done to the main branch.

Power saver mod
Wide menu mod (for my 3.5inch display)

The wide menu mod should not interfere with any other functionality.

cyperghost

That was quick my results are following.
0. I used top

The mod seems to work
I tested on a fresh 4.2 RPi0/1 image
Non overclocked RPi0 attached with 1 WLAN Stick LogiLink, 1 Controller
HDMI output

My outfindings:

Action                  ES branch       CPU usage
--------------------------------------------------
Reboot                  2.1.5RP         30-35%
Select NES 12 Roms      2.1.5RP         65%
Start Rom, back to ES   2.1.5RP         65%
Screensaver DIM 1min    2.1.5RP         10-15%

Reboot                  2.3.2RP PS off  40%
Select NES 12 Roms      2.3.2RP PS off  67%

Reboot                  2.3.2RP PS on   5-10%
Select NES 12 Roms      2.3.2RP PS on   45%
Select NES 12 Roms 5sec 2.3.2RP PS on   5-10%
Start Rom, back to ES   2.3.2RP PS on   65%
Start Rom, back ES 5sec 2.3.2RP PS on   5-10%

Bugs

Screensaver seem to be disabled in this mod ... but this is already told in "Info note"

meleu

@cyperghost said in Testers needed :: Power Saver features :: PR #172:

Screensaver seem to be disabled in this mod ...

The OP says:

Dim and blank screensavers aren't triggered if PS enaled

Then it isn't a bug.

cyperghost

@meleu oh man ... why you are so quick... I just edited that :)
Have a nice sunday brother :D
I'm getting out of here :D Thank you

cyperghost

@Hex
All in all your mod seems to work.
The CPU instantly raises if I disable Power Savings.
Nice solution :) The effect on a RPI2/3 wouldn't be so massive but the 0 and 1 do profit from this!

The 2.1.5 version of ES let's the CPU raise (for ex. NES selection list) and does not drop. Your branch let also the CPU raise but then there is a drop from 60% to 5-10% within a few seconds! Results for 2.3.5RP vs 2.3.2RP PowerSaving listed are listed here

TMNTturtlguy

@hex this look really cool! What are the advantages when running a pi 3? As you know I run video screensaver and video preview all of the time, will my build recieve any benefits?

Thanks for the hard work and cool features!

Hex

@TMNTturtlguy
Briefly : If Video Screensaver is enabled PS is disabled by force.

Video Screensaver works because PS is hardcoded to not work when VS is enabled.

If I were to remove that requirement then VS will not be triggered just like Dim and Blank. All screensavers can be manually triggered though.

PS accounts for Video snaps if the display is set to Automatic. It is enforced if set to Detailed. It is disabled if set to Video.

So if you have video previews and set it to Automatic then PS is disabled when you are on a gamelist which has videos. When you are on a gamelist without videos it is enabled again. It is always enabled on System/Carousel, unless you have disabled PS from settings or you have VS enabled

cyperghost

@TMNTturtlguy The advantages even on a PI3 are clear. The CPU usage is now between 15-20% in idle mode. If Screensaver is activated then trigger buttons are disabeld and the CPU get down to 3-5%. If you use video preview then it may be useless but not every user gots the preview on :)

With PS enabeld it will always be 3-5% (I guess from!) that saves some energy. The effect is not as strong as for the PI1/0 but will be noticable on PI2/3. So I think the branch of "Power Saving mode" makes sense.

I'm still not sure why there are Loops installed that waits for key evenst! @hex Can you explain please? Are you using interrupts?

Hex

@cyperghost in short SDL2 event handling is shit.

How a normal framework should handle key presses

The UI is rendered on the main thread. When a key is pressed, the OS should send an interrupt/signal to the framework. Framework checks which method handles key press and calls that method to handle key press. The method should return if it consumes the key press or not. If key press was not consumed then the framework passes it to its internal key press handler.

How SDL2 handles key press
SDL2 main thread check if user has pressed a key by SDL_pollevent or SDL_waitevent. When a user presses a key it is added to event queue. SDL_poll call checks if there is an event in event queue and returns with the first incoming event (null if no event). the main thread then handles the incoming event and renders the frame accordingly. Since we need lots of frame for smooth animations this has to be put in a timed loop. The timer decides which frame is being rendered.

The problem starts here. Now that you are in a while loop for rendering, what happens if no events are received? You just keep on looping doing nothing but rendering the screen which is not changing, thus consuming CPU.

SDL_Wait come to the rescue. SDL_wait waits for an event to occur and only then returns. so it is a blocking call. If an event doesn't occur, your main thread is not rendering. Hence the CPU savings. But what does SDL_wait do in the background? It just polls and sleeps in a loop till an event occurs, which is stupid.

cyperghost

@Hex Okay I understand. So it's a question of the framwork and the programmer (aloshi?) was forced to use this stupid polling events.

It's really a nice that you made this possible! And I hope that this fix will find it's place in ES development!

Nearby for info @interested:
Polling is a timed loop waiting for events - just stupid. You are doing this if you have really no knowledge how a process is working or the surrounded framework lacks of better techniques. Then you are using polling events! So you let the CPU do something (or let the CPU just waiting in background) and after 100µS you check an event (button press...) and it says "Something happend" or "Nothing happend". Then you can produce errors like bouncing ... make 2 steps instead of one.

The better way is to use interrupts. You use a trigger that stays permanent in memory and this trigger is waiting for an event. If the event has started than a vector jumps back to the programm and says "Something happend!" and that's always better for CPU usage but needs a bit more programming skills!

Think about 2 humans talking to each other.

The Poller:

Person 1: What's up?
Person 2: Nothing!
After 5 minutes
Person 1: What's up?
Person 2: Nothing!
After 5 minutes
Person 1: What's up?
Person 2: Nothing!
After 5 minutes
Person 1: What's up?
Person 2: You get me on the nerves?
Person 1: Really - what you want me to do?
Person 2: Get me out of this

The Interrupter

Person 1: If there is a need for smalltalk... then please tell me! (=set pointer to person 2)
5 min
5 min
5 min
Person 2: It's so boring (=vector back to Person 1 = Interrupt request or IRQ)
Person 1: What you want me to do?
Person 2: Get me out of this

;)

Hex

@cyperghost The programmer Alec "Aloshi" Lofquist, was probably coding on a PC and did not make things for small devices. Stock ES uses 1% at idle on my Linux laptop which equates to 60% on Pi 0.

~~Lets say ES is a worker and OS is his manager. ES is at his desk.~~ Never mind you just edited to add something like this :| And the 5mins is more like 1ms

cyperghost

@Hex
I just wanted to write something everbody can imagine! It's better to talk about a pointer that is setted to a fixed RAM cell and sends a vector back to the pointer with annother value? Of course we are talking about GHz so 1ms is really a long long time :)
Thank you for the technical background.