Global death of AudioTrack

Question

I have an application where there several threads each pumping into a separate AudioTrack set to MODE_STREAM. Switching between apps works fine, and when the application shuts down normally it seems to shut everything down correctly.

However, if the application is terminated externally, such as from the debugger or because I've just installed a new version while the old version was running, it seems that some state in the global AudioMixer gets messed up, and I get logcat output like:

09-16 14:50:38.965   298  7150 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x83c2348 user=00000eb3, server=00000000
09-16 14:50:39.025  7066  7132 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x8249d40 user=00002000, server=00000000
09-16 14:50:40.277   298  7156 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x84cb810 user=00000eb3, server=00000000

and no application that uses AudioTrack is able to play audio ever again, until I reboot my device. In this particular log fragment, PID 298 is system_server and 7066 is the new instance of the application.

What I think is happening is that the AudioTrack is disappearing before the writer thread has a chance to clean up. This makes me think that there is something else I should be doing to clean up. I'm already trapping my Activity's onStop and onDestroy and having those shut down my audio threads, but is there another place that this needs to happen?

Also, is there a better way to clean up AudioTrack? It seems like this part of Android is especially fragile, but I can't imagine that everyone uses SoundPool and MediaPlayer for everything, as those APIs are very limited and fiddly (and both seem to just wrap AudioTrack in different ways anyway).

Answer 1

Unfortunately your app gets no warning before it is killed by the OS and replaced with a new version. You can test this with a very simple Activity where the onPause() onStart() onStop() and onDestroy() methods produce log messages. If you install a new version of the app the messages in the onStop() and onDestroy() methods never get produced.

With regards to the AudioTrack problem, that is probably a bug your device's audio drivers. Some people trying to port Android get similar problems due to bad drivers. Additionally, one of the other answers to this question leads me to believe this as well. If this problem is restricted to a subset of phones from a few manufactures and not all phones then this that suggests the manufacturer's sound drivers are bad.

Have you considered using the MediaPlayer API instead of AudioTrack. It doesn't have the same flexibility but it could be a viable workaround. Here is a nice comparison of the three different audio apis.

One possible work around is to actually split the app into two a separate apks for debugging. One does nothing but plays the audio and is controlled by the second app. This way whenever you install an updated controller the binary playing the audio is unaffected and doesn't experience the abrupt kill and re-install. Then when you are ready to distribute the app simply combine the two into a single apk and then distribute that.

Answer 2

I know this particular problem from a lot of Motorola devices I've developed with. Is your device from the Droid series? Anyway, the best I can tell is that Motorola should be informed about that a lot of times until they bother to fix it.

Killing the process bypasses the Activity's lifecycle, so you do nothing wrong.