Crericper

Oh, I thought compressor is a feature is to shift frequency from e.g. 20Hz to 60Hz, which, you know, is somehow similar to the HDR filter in photography, to compress audio dynamic range. And I'm also not sure if there is anything existing like that. 😂

@andrewilley However, it's different on my situation. As I said before, Compressor is greatly helpful on fixing that. And also,

In my case it's the JBL filp 3 speaker that does not respond to frequency lower than 60Hz, which some songs sound strange with that issue. I need this feature as well as the people in this thread. It should be much easier to code than the reverb, right? p.s. If possible, please also add a button to disable pitch normalization during tempo adjustment. That is extremely useful for Nightcore songs!

@RBEmerson, it was a thread that checks play service, but went into infinity loop, and I think, it is most likely caused by play service not responding. Quotes here:

Bravo!! 🎉

Glad to see it finally had worked out!!! 😄

This is the log for pa launched at 'Folder'. I logged this with the same steps performed as before. But this time pa did not wait for any kind of weird thread. alogcat.2019-11-08-07-41-10+1100.txt

1. Switch to PA, with a playlist loaded 2. Go to next song using the main interface, not the notification interface (note: actually playing a song is not required) 3. Switch to OS monitor or SystemPanel (or any other app) 4. Notice that Poweramp CPU usage increases and stays high, specifically that it maxes out a single CPU core @maxmp, have you got the bug successfully reproduced on your end? Or is that the case where the bug only applies to only me and @dinfinity?

Ah, forgot to post my device & info. In case if you need @maxmp. Model: Xiaomi MI 6 Android: 8.0.0 ROM: MIUI 10 9.3.21 Beta Security patch level: 2019-04-05 Kernel: 4.4.78-perf-ge57b3e5 CPU: Snapdragon 835 8-Core @ 2.45GHz RAM: 6.00GB Avaliable Storage: 9.37GB Poweramp version: v3-build-852-arm64-play SHA-1: 3dfe11e642d0cdc8cb2941198f732ca2007e93e3 Unlocker version: 3-build-301 SHA-1: e9e324843197257366074a3027eda6ed3adf5f25 @dinfinity, I believe that's the case as well! That instance have also appeared in the first log I've posted. (Notice there's the orange chunk below.) Here quotes:

After some extra digging, found this: Seems like it is waiting for a thread to stop: "awakenReason":1,"stack":["java.lang.Thread.join(Thread.java:1268)","com.maxmpz.audioplayer.player.PlayerService.onDestroy","android.app.ActivityThread.handleStopService"... As:

@maxmp, sorry that the developer logging wasn't functional on my phone. But you may still find this useful. Information below will be based on the log made by rs.pedjaapps.alogcatroot. I've reproduced the issue 3 times for logging, each time I ensure CPU goes up before continuing. 1. Start Poweramp 2. Swipe for next song 3. Switch to SystemPanel and wait 4. Switch back to Poweramp 5. Repeat step 2-4 two more times Then I've filtered the log with keyword "maxmp", which should only return Poweramp related instances. Here's a screenshot of the filtered & formatted log. I circled everything related to the suspecious "dsp_thread". I have also included a text-based log. Hope you find this useful, thanks! alogcat.2019-11-07-14-24-07+1100.txt

Quick update: Via @dinfinity's new method, I've got the issue reproduced consistantly out of 5 times. This discovery made contribution to log quality as less instance means cleaner log.

To determine CPU usage, you can use SystemPanel. For rooted users, it will show CPU usage for each process individually. For non-rooted users, you probably can determine system load change by using it, but it is very unresponsive and hard to see. So, I'd recommend either go for a temperature change or a battery current change, which can be monitored via lots of apps (including SystemPanel).

@RBEmerson, @Moho Miner, @qwqwas1122, @krazzyvishal Can you confirm if @dinfinity's method also applies to you guys? And everyone else upcoming please do so as well! This can be very helpful in determining the cause of the problem. Thanks.

I've reproduced the bug twice and logged it with LogcatX. Inside this screenshot, the selected 3 lines seems suspicious. Log_2019-11-01_22-09-24.zip