I have an application which records audio via microphone and directly encodes the raw PCM-data to MP3 via LAME (configured for most performance), before sending that stream via HTTP.
On my Galaxy S5, it's working flawlessly while screen is ON, but seconds after turning the screen OFF, the process get's struggling due to lack of CPU.
I'm using all known required options to prevent the device from sleeping and theoretically it's working as the CPU does not sleep, but just scaling the CPU too low:
service is running in foreground-state
I have a WIFI_MODE_FULL_HIGH_PERF-lock
and a PARTIAL_WAKE_LOCK to prevent the CPU from sleeping
priority of all affected threads is set to android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO);
The application is theoretically working very well and used on hundred of thousand devices meanwhile.
But if the user is using the MP3-encoder + screen off, there is a chance that the CPU doesn't deliver enough power anymore to encode + stream the data smooth.
The CPU-governor of my S5 is "interactive" - if I set it to "performance", the problem is gone.
Anybody an idea how to prevent Android from sleeping, without using root to change the governor all the time the app is in use?
Related
I have a non-PlayStore app for Tablet devices where I have embedded YouTube videos in a FullScreenActivity. Code is pretty standard as per the documentation. However, I find the video playback quite laggy and it keeps buffering. To figure out what's happening, I started measuring things.
Device is Rockchip RK3368, 1GB Ram, 15.6 inch IPS display, 1920x1080, Android 6.0
1) Bandwidth - Have a 50 Mbps connection, face no problem with YouTube in any other device.
2) Memory - The device does have 1 GB memory, it may be less but I have no app other than stock ones installed and when I check for free memory it is generally more than 250 MB.
3) Processing power - It's an 8 core RK3368 CPU, however, after turning 'Show CPU usage' on, I see the device (the number for average cpu usage for time interval 1 minute) goes from about 5 to 20 or higher. This is when everything starts hanging in the tablet. Pressing back button or home button takes many many seconds to even register (that is show the ripple animation).
On closing the activity, the tablet is back to normal in about half a minute.
Turning hardwareAccelerated to true has helped a little but it is still unusable.
Please let me know how to improve the performance.
Please bear with me. I will provide any code/info/run tests if you need. Thanks in advance.
As I know Google added possibility to capture screen using adb in Android 4.4 with 30 fps. Is there exist any way to transfer screen from Android 4.4 device with such speed? I used framebuffer, but it's too slow.
Thanks.
There is no such way. Neither USB nor WLAN is fast enough to transmit uncompressed high-resolution video at 30fps. You could try to do real-time compression on the device and transmit compressed video, but I suspect that that will starve the app you're recording of CPU and thereby make the recording unrealistic.
Sorry.
I have an OpenGL game for Android. It runs at a good 60fps when the screen is touched. When I release my finger it goes back down to around 30fps. Does the touch event/release raise/lower a thread's priority and if so how can I replicate this to keep it at a constant 60fps. This only seems to be an issue on Galaxy Note 2 so far.
I'll assume you are using onDrawFrame and setRenderMode(RENDERMODE_CONTINUOUSLY).
30 and 60FPS indicates that your implementation of onDrawFrame is called as the device's screen refreshes. Most displays refresh at 60Hz, giving you 60FPS.
It is likely that the Galaxy Note 2 has some power saving feature that limits screen refresh to 30Hz when there are no touches on screen. Check if there's any way to disable this feature.
AFAIK, OpenGL ES does not specify a standard for screen refresh rates, you will need a throttling function to ensure that your game runs/feels the same (i.e. at the same speed) despite differences in FPS.
Yes.
The best way to observe this phenomena is to use systrace with the "freq" tag enabled. You probably need a rooted device, and you definitely need one on which systrace is enabled.
systrace will record changes in the clock frequency for various components. It varies by device, but you can usually get the per-core CPU clocks and GPU memory rate. You will likely see several of them drop significantly at the same time your frame rate drops.
The motivation for doing this is to reduce power requirements and extend battery life. The assumption is that, while your finger is in contact with the screen, you're actively doing something and the device should be as responsive as possible. After a brief period of time, the clocks will slow to a level appropriate for the current workload. The heuristics that determine how long to wait before slowing, and how much to slow down, are tuned for each device.
(This has caused some people to create a thread that just sits and spins on multi-core devices as a way to artificially prop up the CPU clock rate. Not recommended. See also this answer.)
The bottom line is that this isn't a simple matter of adjusting thread priorities. You have to choose between recognizing that the slowdown will happen and adapting to it (by making your game updates independent of frame rate), or figure out some way to fool the device into staying in a higher-power mode when you want smooth animation.
(For anyone who wants to play along at home: build a copy of Grafika and start the "Record GL app" activity. If you drag your finger around the screen all will be well, but if you leave it alone for a few seconds you may start to see the dropped-frame counter rising as the app falls behind. Seen on Nexus 5, Nexus 7 (2013), and others.)
I am making an Android app that plays audio and does heavy amounts of DSP. Using BetterBatteryStats, I've found on the HTC One X that when the screen is off the CPU throttles back to 384 MHz. This speed is too slow for DSP processing I am trying to do.
Is there a way to keep the HTC One X from moving to such a slow speed without keeping the screen on? A partial wake lock does not seem to be cutting it.
My app holds a partial wakelock (to ensure the CPU keeps running) and also uses a proximity wake lock to turn the screen off if the user holds the phone near their face. The app plays audio to the user using its own native threads and the OpenSLES api.
The problem I have is that when the proximity sensor triggers and the screen turns off the CPU appears to slow down and the native threads can no-longer keep up and the audio stutters.
Anyone know what's going on here and if there's anything I can do about it?
Regards
Phil
What I really needed was a high performance wifi lock - it was actually the wifi that was the problem, not the CPU.
See http://developer.android.com/reference/android/net/wifi/WifiManager.html#WIFI_MODE_FULL_HIGH_PERF