0

I'm using openSL ES in one of my Android apps. When the app is in the foreground the callbacks are pretty regular. The mic callback is called approximately every 10ms and so is the speaker callback. However, if I put my app in the background and open up a browser (or another app for that matter) I see that a "storm" of callbacks are triggered upon opening up the browser (or browsing). Is there a way to get around that? And why does it happen? Is openSL compensating for a period of time where it wasn't able to execute the callbacks? (like it's trying to catch up).

My source code is in C and I'm on Jelly Bean 4.3.

I have tried to increase the thread priorities of AudioTrack and AudioRecorder, and it does seem to help, but I'm not sure that's the way to go.

ADDITIONAL QUESTIONS

So you're saying that even with increased thread priority you might get a burst of callbacks and that you should discard those ?

How is that a good solution? You'll be dropping mic packet (or draining the source of the speaker packets), right? If you don't drop mic packets, the receiver of the mic packets will interpret the burst of mic packets as excessive jitter, right?

More importantly: I manually increased the thread priority of AudioTrack and AudioRecorder and changed the sched policy to round robin. It required both root access and installation of BusyBox (which comes with a command line util for changing thread priorities/sched policy). How is this done programatically from C ? I want to make sure that it IS the individual thread priority that is increased and not just the priority of my app (process).

user1884325
  • 2,530
  • 1
  • 30
  • 49

1 Answers1

1

Yes, this is by design. Trying to push the thread priority high is the legitimate way to work around. Make sure to work with native buffer size and sampling (see Low-latency audio playback on Android) for best results. You should still be prepared to discard bursts of callbacks because there is no way to guarantee they will never happen. You should also try to reduce overall CPU consumption and RAM footstamp of your app while it is in the background.

Community
  • 1
  • 1
Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • So you're saying that even with increased thread priority you might get a burst of callbacks and that you should discard those ? How is that a good solution? You'll be dropping mic packet (or draining the source of the speaker packets), right? If you don't drop mic packets, the receiver of the mic packets will interpret the burst of mic packets as excessive jitter, right? I have edited my original question. Could you please address the additional questions? Thank you. – user1884325 Dec 18 '13 at 19:22
  • More answers: I didn't say it's good that the bursts may still happen even if you try hard; but unfortunately there are simply no guarantees the callbacks will always arrive with negligible jitter. Don't kill the messenger. – Alex Cohn Dec 18 '13 at 21:45
  • Regarding rooting and tuning the thread scheduler, methinks it's a wrong path. If you are building a custom HW solution based on Android, you probably should apply some RT patches to the kernel first. Otherwise, the bursts will still happen, even if less often. At any rate, you [can set individual thread priority](https://groups.google.com/forum/m/#!topic/android-developers/b2SKprSxPvw) as high as `Process.THREAD_PRIORITY_URGENT_AUDIO = -19;`, see – Alex Cohn Dec 18 '13 at 21:57
  • Alex: How do you detect in C if the mic is in use by another app? openSL doesn't seem to provide a way of detecting that or it doesn't report back if the mic is in use !??! – user1884325 Dec 19 '13 at 23:12
  • IIRC, the audio focus should be handled in Java – Alex Cohn Dec 20 '13 at 05:22