Re: C thread realtime priority when application backgrounded.

[Glenn Kasten]

Android app threads run with the SCHED_OTHER/SCHED_NORMAL scheduling policy, which is implemented using CFS scheduler. CFS attempts to provide fairness over long-term, but not instantaneous predictability. You can adjust the nice priority level, using setpriority(2). The nice priority is an input parameter to CFS decisions, but it doesn't change the fact you're using CFS.

There are other scheduling policies settable with sched_setscheduler(2) but the interesting ones require additional permission beyond what apps have.

As a workaround I suggest: (a) run at elevated nice priority, (b) use larger buffers, (c) don't use interfering features during recording ... e.g. don't run other apps, turn off radios, etc.

On Friday, August 24, 2012 8:47:24 AM UTC-7, A.T. wrote:

Hi Folks,

I'm building a custom application on a custom device (2.3.5, kernel 2.6.38). The android device is acting as a USB Host, consuming audio from a connected USB media player device using standard USB Audio Class. I do have access to generate a new ROM for the custom device.

In a C thread (record thread), I'm opening a handle to the USB alsa recorder device (/dev/snd/), requesting pcm frames from the attached USB device using the snd_pcm_readi alsa API. Frames are now passed from recorder thread to a C playback thread to be queued to speaker output via ALSA and/or OpenSL.

When my application is in the foreground, the recorder thread runs in a timely manner, and audio playback is seamless. However, when my application gets backgrounded, I run another application in forground, or quickly scroll through any listviews or the home screen tiles, the C recorder thread gets starved. The C recorder thread cannot request USB audio frames fast enough, and music starts to skip. When the forground application idles again or I finish interacting with the UI, the music will once again be seamless.

As I understand, C threads in Android do not (and cannot) have real-time priority, verified by my failed attempts to bump up the pthread priority. My view of the solution is to bump up the recorder thread priority somehow, but not sure how to get beyond the android thread priority limitation. Or is there another solution (like not having a recorder/playback thread, and using builtin media features)?

Open to all suggestions or comments.

Thanks in advance.
AT

[Dianne Hackborn]

When applications go into the background, the system puts all of their threads in the background scheduling group so that they won't interfere with foreground operation.  The correct way to avoid this (avoid your app from going into the background) is to set your service to be foreground.  If you are doing critical work there are many reasons you want to tell the system that your executing service is in the foreground: besides scheduling, this also tells it that it needs to ensure the process isn't killed for memory -- regular background services are allowed and expected to be killed arbitrarily while they are running, since they are by definition not things the user is directly aware of.

On Fri, Aug 24, 2012 at 8:47 AM, A.T. <alc...@gmail.com> wrote:

Hi Folks,

I'm building a custom application on a custom device (2.3.5, kernel 2.6.38). The android device is acting as a USB Host, consuming audio from a connected USB media player device using standard USB Audio Class. I do have access to generate a new ROM for the custom device.

In a C thread (record thread), I'm opening a handle to the USB alsa recorder device (/dev/snd/), requesting pcm frames from the attached USB device using the snd_pcm_readi alsa API. Frames are now passed from recorder thread to a C playback thread to be queued to speaker output via ALSA and/or OpenSL.

When my application is in the foreground, the recorder thread runs in a timely manner, and audio playback is seamless. However, when my application gets backgrounded, I run another application in forground, or quickly scroll through any listviews or the home screen tiles, the C recorder thread gets starved. The C recorder thread cannot request USB audio frames fast enough, and music starts to skip. When the forground application idles again or I finish interacting with the UI, the music will once again be seamless.

As I understand, C threads in Android do not (and cannot) have real-time priority, verified by my failed attempts to bump up the pthread priority. My view of the solution is to bump up the recorder thread priority somehow, but not sure how to get beyond the android thread priority limitation. Or is there another solution (like not having a recorder/playback thread, and using builtin media features)?

Open to all suggestions or comments.

Thanks in advance.

AT


--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/IbVhht7tocoJ.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.