Tips for improving stability when playing audio in background app about mwengine HOT 7 CLOSED

Adding android.os.Process.setThreadPriority(Process.THREAD_PRIORITY_URGENT_AUDIO); seems to help a lot. Thanks for the help!

from mwengine.

Cool! Glad it works for you, the contents of that branch will be merged to the master branch soon so more people can enjoy this ;)

from mwengine.

Thanks for the insights! I did the same check when moving the setThreadPriority() call to the run() method to verify the results. I agree this should definitely improve overall stability (regardless of suspension state of the application).

The branch is now merged into master.

from mwengine.

Hi,

interesting question as MWEngine example Activity suspends all threads when the application loses focus. The issue at hand here is that the threading priority changes which leads to buffer callbacks being called too late causing audio to drop out.

If you check out the branch pshifter of this repository, you will have an updated version of the engine (still under development, mostly for the pitch shifter module as the branch name suggests). This updated engine has the maximum threading priority for urgent audio, this should hopefully keep the Linux FIFO scheduling intact when the app is suspended.

from mwengine.

After digging into this a bit more, I'm wondering if it's actually necessary to call android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO) from the run() method in MWEngine instead of in its constructor. The setThreadPriority(int) method sets the priority of the "calling thread," which is not the MWEngine thread in the constructor, but rather whichever thread calls the constructor. If we want the MWEngine thread to have increased priority, it seems like the setThreadPriority(int) method should be called inside the run() method instead.

Does this make sense? Thanks!

from mwengine.

Hm, when a thread is created in Java, it inherits its priority from the thread that created it. But then again that does imply that (in the current example) multiple threads will demand the same priority, which is not what we want at all obviously.

There is also some confusion as to whether to use the Java standard Thread.setPriority() or the Android example android.os.Process.setThreadPriority() apart from the fact that Google states the latter "names a real thread priority of the underliying linux OS" (preferable) and the enumeration range is larger, the difference is unclear.

I have moved the setThreadPriority() call to the run() method as per yours and Googles suggestion and pushed to the pshifter branch. Curious to hear about your findings.

from mwengine.

I think the Java Thread.setPriority() only sets priority in relation to other threads in your process, whereas android.os.Process.setThreadPriority() sets priority in relation to all other threads in the OS. I'm not positive about that though.

Also, I don't think that these android.os.Process thread priorities are inherited from the thread's creator. I did some logging like this:

int tid = android.os.Process.myTid(); // Priority of the calling thread
int priority = android.os.Process.getThreadPriority(tid);
Log.d("testing", "MWEngine run(), tid: " + tid + ", priority: " + priority);

in an Activity class (the main thread), the MWEngine constructor, and the run() method, and saw that the main thread has an android.os.Process priority of -10 whereas the MWEngine thread in the run() method has a priority of 0.

Calling android.os.Process.setThreadPriority(android.os.Process.THREAD_PRIORITY_URGENT_AUDIO); from the run() method changes the MWEngine thread's priority (logged in run()) to -19, as expected.

I should also add that calling android.os.Process.setThreadPriority(19); from the run() method (19 is the lowest thread priority) has a very obvious negative impact on audio stability, especially when the app is in the background.

from mwengine.