AudioTrack的全球死亡

Question

我有一个应用程序,其中有几个线程,每个线程都被设置为单独的AudioTrack MODE_STREAM.在应用程序之间切换工作正常,当应用程序正常关闭时,它似乎正确关闭所有内容.

但是,如果应用程序在外部终止,例如从调试器终止,或者因为我刚刚在旧版本运行时安装了新版本,似乎全局AudioMixer中的某些状态搞砸了,我得到类似logcat的输出:

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

并且没有使用AudioTrack的应用程序能够再次播放音频,直到我重新启动设备.在此特定日志片段中,PID 298是system_server,7066是应用程序的新实例.

我认为发生的事情是AudioTrack在作者线程有机会清理之前就消失了.这让我觉得我应该做些什么来清理.我已经俘获我的活动的onStop,并onDestroy和那些具有关闭我的音频线,但有这个需要做的另一个地方？

另外,有更好的方法来清理AudioTrack吗？看起来Android的这一部分特别脆弱,但是我无法想象每个人都会使用SoundPool和MediaPlayer来处理所有事情,因为这些API非常有限且非常繁琐(而且两者似乎都以不同的方式包装AudioTrack).

Answer 1

不幸的是,您的应用程序在被操作系统杀死并被新版本替换之前不会收到警告.您可以使用一个非常简单的Activity来测试它,其中onStause()onStart()onStop()和onDestroy()方法产生日志消息.如果安装新版本的应用程序,onStop()和onDestroy()方法中的消息永远不会生成.

关于AudioTrack问题,这可能是设备的音频驱动程序的错误.有些人试图移植Android会因为驱动程序不良而遇到类似问题.此外,这个问题的其他答案之一让我也相信这一点.如果这个问题仅限于来自少数制造商而非所有手机的手机的一部分,那么这表明制造商的声音驱动器是坏的.

您是否考虑过使用MediaPlayer API而不是AudioTrack.它没有相同的灵活性,但它可能是一个可行的解决方法.这是三种不同音频apis的比较.

一个可能的解决方法是将应用程序实际拆分为两个单独的apks以进行调试.一个人什么也不做,只播放音频,并由第二个应用程序控制.这样,无论何时安装更新的控制器,播放音频的二进制文件都不受影响,并且不会遇到突然终止和重新安装.然后,当您准备分发应用程序时,只需将两者合并为一个apk,然后分发即可.