Глобальная смерть 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 своей деятельности и отключаю их, но есть ли другое место, где это должно произойти?

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

Answer 1

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

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

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

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

Answer 2

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

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