High CPU usage

[ghost]

Checklist

• I am using the latest version - 0.21.9
• [x ] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• [ x] I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• [ x] This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

Search for any song.
Press background play
Measure cpu time with adb shell top
Turn the screen off to disable gui to make sure gui is not rendering something

Actual behavior

CPU usage either 6% or 10% in top for newpipe process

Expected behavior

0% cpu usage for newpipe process as with other players where only media.codec is using 1% cpu

Device info

Moto G4 stock
Android 7

[litetex]

Okay I debugged this a bit:

Used video: https://www.youtube.com/watch?v=GDqxvHSPu5c
Quality: 360p

Device: Huawei P20lite (CPU: 4x 2.36 GHz, 4x 1.7 GHz)
Complete available CPU-percent on device: 800% (8 cores)
OS: Android 9.1 / EMUI 9.1

App	Mode	CPU usage details (from/max=800%)	complete avg CPU usage of all related apps (calculated down to max=100%)
NewPipe	Normal or Full screen	30-50% NewPipe + 14% media.codec + 11% surfaceflinger + 11% audioserver	9.5%
NewPipe	Background (app closed on homescreen)	30-50% NewPipe + 14% media.codec + 11% audioserver	8.1%
Youtube	Normal or Full screen	30-50% YouTube + 5% media.codec + 13% surfaceflinger + 10% audioserver	8.5%
Built-in audio player	Background (app closed on homescreen) m4a file	5% huawei music player + 13% audioserver + 11% media.codec + 11% mediaserver	5%

Turn the screen off to disable gui to make sure gui is not rendering something

GUI rendering is done on the GPU side and should have little to no effect on the above mentioned cpu processes

So in my opinion everything works as expected:

• The YouTube app is a bit faster because it likely uses better codes than NewPipe (media.code only requires half the cpu compared to NewPipe)
• Running the built-in music player doesn't require any network-I/O activity (as can be seen when as the apps cpu usage is only 1/6-1/10 compared to YT or NewPipe) however it requires the additional process mediaserver

[litetex]

@thefalsedev
I also added the missing checklist, please fill it out 😄

[ghost]

I am comparing it now with youtube vanced music.
On vanced on the same file I am getting 2-3% cpu usage for vanced process and 1% for media.codec.
On newpipe I am getting either 6%-10% depending on whatever I dont know. Right now I am getting 7% and it's stable. When I restart it I am getting anything between 6 and 10 (in apps force stop).
Note that this is constant usage and has nothing to do with the network, as network is using only momentary.
This was tested on the same AAC file.
Also note this has impact on how long you can go outdoors and listen to the music however I havent tested it yet, but i will test it ASAP.
Basically by using adb shell dumpsys battery I can check actual battery usage and how big impact it is.
I think youtube app is not good comparison as it's total crap.
OK I restarted it properly now and I am getting 6%. Looks like it starts at 6 and keeps growing or something, will keep an eye on this.

For newpipe:

PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
14426 u0_a245  20   0   6% S    59 1166856K 126628K  fg org.schabi.newpipe
3664 mediacod 20   0   1% S    16 120608K   2772K  fg media.codec

For vanced:

PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
14945 u0_a130  20   0   3% S   146 1876368K 162936K  fg com.vanced.android.apps.youtube.music
3664 mediacod 20   0   1% S    18 122832K   3484K  fg media.codec

For musicolet opus file:

3664 mediacod 20   0   1% S    20 125280K   3628K  fg media.codec

We are talking about new pipe process and not other processes, and with the screen turned off while you are outdoors.

[ghost]

After couple of songs it got 7% and after another few it has now 8%. I measured the battery, it consumes 0.041 mAh per second so far so it gives 16h playback. I think it's not bad compared to other players I got and their playtime.
However this growing cpu usage is concerning so if it continues to grow then the practical playtime will get reduced.
I will keep playing and measuring the battery load.

   PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
14426 u0_a245  20   0   8% S    71 1193852K 121140K  fg org.schabi.newpipe
 3664 mediacod 20   0   1% S    16 120608K   2376K  fg media.codec

The threads are looking like this:

  PID   TID USER     PR  NI CPU% S     VSS     RSS PCY Thread          Proc
14426 14436 u0_a245  20   0   5% S 1177052K 119672K  fg HeapTaskDaemon  org.schabi.newpipe
14426 16142 u0_a245   4 -16   1% S 1177052K 119672K  fg ExoPlayer:Playb org.schabi.newpipe
17821 17821 shell    20   0   1% R  13640K   2392K  fg top             top
 3664 17775 mediacod 18  -2   0% S 120608K   2172K  fg le.opus.decoder media.codec

For now, for over 35min it consumed 0.046 mAh per second.

[ghost]

In vanced there is no HeapTaskDaemon working, hence lower cpu usage:

  PID   TID USER     PR  NI CPU% S     VSS     RSS PCY Thread          Proc
14945 15061 u0_a130   4 -16   1% S 1903412K 149948K  fg ExoPlayer:Playb com.vanced.android.apps.youtube.music
18499 18499 shell    20   0   1% R  13640K   2416K  fg top             top
14945 18394 u0_a130  18  -2   0% S 1903412K 149948K  fg MediaCodec_loop com.vanced.android.apps.youtube.music
 3664 18395 mediacod 18  -2   0% S 122832K   3580K  fg gle.aac.decoder media.codec
14945 14945 u0_a130  20   0   0% S 1903412K 149948K  fg s.youtube.music com.vanced.android.apps.youtube.music
  546   659 system   11  -9   0% S 168760K   7216K  fg EventThread     /system/bin/surfaceflinger
 3664  3914 mediacod 20   0   0% S 122832K   3580K  fg Binder:3664_3   media.codec
 3664 18396 mediacod 18  -2   0% S 122832K   3580K  fg OMXCallbackDisp media.codec
    7     7 root     20   0   0% S      0K      0K  fg rcu_preempt     

This seems that this HeapTaskDaemon has something to do with garbage collection. So it could be something is allocating and deallocating memory during playback.

[ghost]

Ok over 1500s the vanced player with the same album on minimal volume consumed less power and so far it seems stable for 10 last minutes. I watched other processes and in both measurements nothing was happening like updates or some workers.
Vanced consumed 0.038 mAh per second, so it gives 21% more power for newpipe which consumed 0.046 mAh.

Note that this supposedly garbage collection sometimes goes higer so the excessive power usage could hit 40% more no problem. I keep now playing now in newpipe to see if it goes any higher just from network playback.

[ghost]

After a while of playing with the app, the HeapTaskDaemon increased to 7%:

14426 14436 u0_a245  20   0   7% R 1226820K 175644K  fg HeapTaskDaemon  org.schabi.newpipe
14426 24659 u0_a245   4 -16   1% S 1226820K 175644K  fg ExoPlayer:Playb org.schabi.newpipe
24832 24832 shell    20   0   1% R  13640K   2352K  fg top             top
 3664 24688 mediacod 18  -2   0% S 120608K   3444K  fg le.opus.decoder media.codec
14426 24687 u0_a245  18  -2   0% S 1226820K 175644K  fg MediaCodec_loop org.schabi.newpipe

I think this can be related to the total ram usage of the app in this case 175M.

[ghost]

So I traced this to player and the progress loop firing too often. I did some changes and so far in emulator it's sometimes just 0.2% garbage collector cpu or whatever it is. Will test on that moto g4 player the release and compare.

[ghost]

After disabling updating of progress in player there is 3% CPU usage as it should be:

  PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
16140 u0_a248  20   0   3% S    66 1204396K 145220K  fg org.schabi.newpipe.debug
 3664 mediacod 20   0   1% S    15 119744K   4092K  fg media.codec

Threads:

  PID   TID USER     PR  NI CPU% S     VSS     RSS PCY Thread          Proc
16140 16533 u0_a248   4 -16   2% S 1204396K 145756K  fg ExoPlayer:Playb org.schabi.newpipe.debug
16601 16601 shell    20   0   1% R  13640K   2400K  fg top             top
 3664 16542 mediacod 18  -2   0% R 119744K   3796K  fg gle.aac.decoder media.codec
16140 16541 u0_a248  18  -2   0% S 1204396K 145756K  fg MediaCodec_loop org.schabi.newpipe.debug
 4792  4909 system   20   0   0% S 1583176K 129112K  fg ActivityManager system_server
 3664 16543 mediacod 18  -2   0% S 119744K   3796K  fg OMXCallbackDisp media.codec
    7     7 root     20   0   0% S      0K      0K  fg rcu_preempt     
16140 16153 u0_a248  20   0   0% S 1204396K 145756K  fg Binder:16140_2  org.schabi.newpipe.debug
 3673  3784 u0_a180  20   0   0% S 1996172K  79484K  fg Lacrima_startup com.facebook.orca
11148 11172 u0_a122  20   0   0% S 1014384K  27760K  fg McsHandler      com.mgoogle.android.gms:persistent

Now need to figure out how to start and stop this update loop properly. Right now it's firing thousdand times a second but should every 500ms.

I dont fully understand how this SerialDisposable is supposed to work with stopping and starting progress loop.

[ghost]

It seems that this progress bar is just too slow to update. But, the number of firings per second can be reduced from 2 to 1. So every 1 second as it's one second anyway. After such change it has 2% less CPU usage so by 30% of the whole process.

  PID USER     PR  NI CPU% S  #THR     VSS     RSS PCY Name
26453 u0_a261  20   0   4% S    64 1167388K 135488K  fg org.schabi.newpipe.debug

This is good and works fine, in Player.java, just change this:

public static final int PROGRESS_LOOP_INTERVAL_MILLIS = 1000; // 1 second

However the best would be to make player progress loop stop when screen is off for optimal power consumption.
I tried stopProgressLoop() when useVideo(false) but this doesnt work, and it would not be optimal anyway so I'll try something else maybe.

[litetex]

I think we can close this issue as it was fixed with #7071