Глобальная смерть AudioTrack

У меня есть приложение, в котором есть несколько потоков, каждый из которых накачивается в отдельный 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 является системным_сервером, а 7066 - новым экземпляром приложения.

Я думаю, что происходит, что AudioTrack исчезает, прежде чем поток писателя сможет очистить. Это заставляет меня думать, что есть что-то еще, что я должен делать, чтобы очистить. Я уже улавливаю свою активность onStop и onDestroy и заставляю их отключать мои аудиопотоки, но есть ли другое место, которое это должно произойти?

Кроме того, есть ли лучший способ очистить AudioTrack? Похоже, эта часть Android особенно хрупка, но я не могу себе представить, что все используют SoundPool и MediaPlayer для всего, так как эти API очень ограничены и сбиты с толку (и оба, похоже, просто обертывают AudioTrack по-разному).

Ответ 1

К сожалению, ваше приложение не получает предупреждения, прежде чем оно будет уничтожено ОС и заменено новой версией. Вы можете проверить это с помощью очень простой операции, в которой методы onPause() onStart() onStop() и onDestroy() генерируют сообщения журнала. Если вы устанавливаете новую версию приложения, сообщения в методах onStop() и onDestroy() никогда не создаются.

Что касается проблемы AudioTrack, возможно, это ошибка драйверов устройства. Некоторые люди, пытающиеся подключиться к Android, получают аналогичные проблемы из-за плохих драйверов. Кроме того, один из других ответов на этот вопрос заставляет меня поверить в это. Если эта проблема ограничена подмножеством телефонов от нескольких производителей, а не со всеми телефонами, то это означает, что звуковые драйверы производителя плохие.

Рассматривали ли вы использование MediaPlayer API вместо AudioTrack. Он не обладает такой же гибкостью, но может быть жизнеспособным решением. Вот хорошее сравнение трех разных аудио файлов.

Одна возможная работа - фактически разделить приложение на два отдельных apks для отладки. Один не делает ничего, кроме воспроизведения звука и контролируется вторым приложением. Таким образом, всякий раз, когда вы устанавливаете обновленный контроллер, двоичный звук, воспроизводящий звук, не изменяется и не испытывает внезапного убийства и переустановки. Затем, когда вы будете готовы распространять приложение, просто объедините их в один apk и затем распространите его.

Ответ 2

Я знаю эту конкретную проблему из многих устройств Motorola, с которыми я разработал. Ваше устройство из серии Droid? В любом случае, самое лучшее, что я могу сказать, это то, что Motorola должна быть проинформирована об этом много раз, пока они не потрудились ее исправить.

Убивание процесса обходит жизненный цикл Activity, поэтому вы ничего не делаете.