Почему onPeriodicNotification () работает так хаотично?
Фон
Я работаю над аудио-визуализатором для Android, который сэмплирует с микрофона, используяAudioRecord.read () (16-битный моно).Я провел немало тестирования с частотой дискретизации и периодами кадров для setPositionNotificationPeriod ().В итоге я остановился на:
Частота дискретизации: 8000
Период кадра: Частота дискретизации * 41/1000 = 328
Размер буфера: 5 * Частота дискретизации
Период кадра составляет 41 мс, который я выбрал, потому что я хочу ~ 24 кадра в секунду для моего визуализатора.
Я думал, что рисование на холсте с такой скоростью поначалу будет проблемой, но после тестирования на DroidX и Nexus One у меня была потрясающая производительность.Я могу уменьшить задержку до 20 мс на этих устройствах без переполнения буфера, но в этом нет необходимости.
Как только я начал тестирование на Galaxy S и Nexus S, моя производительность пошла на спад.Это казалось странным, поскольку Nexus S значительно превосходит оба устройства.После устранения рисования и вычислений как проблемы, я поместил вызовы синхронизации в onPeriodicNotification ().Мне удалось подтвердить, что проблема связана с тем, что этот обратный вызов вызывается с произвольным интервалом времени, и я не понимаю, почему.
Создание эталонного теста
Как честногоВ ходе теста я взял всю свою обработку звука и вывод из цикла так, что все мое приложение выполняет чтение аудио в цикле и регистрирует данные в onPeriodicNotification ().Я установил период кадра в 100 мс и использовал следующий временной код:
currentTime = SystemClock.elapsedRealtime();
Log.v(TAG, "time since last record update: " + (currentTime - lastTime));
lastTime = currentTime;
Наконец, я выбрал данные в течение 5 минут на каждом устройстве.На DroidX я получаю примерно то, что ожидаю:
# Очки: 3008
Мин: 92
Макс: 105
Avg: 100
StdDev: 6.64
Это кажется разумным, и я готов с этим жить.На Galaxy S я получаю это:
# Очки: 3004
Мин .: 0!
Макс: 274
Avg: 100.05
StdDev: 126.30?!?
При StdDev 126 это означает, что последующий набор вызовов синхронизации часто выглядиткак это [253, 0, 1, 258, 1, 0, 263].
Заключение и другие разносторонние данные
Во время выполнения этих тестов я следил за использованием процессора,Мой процесс потребляет около 2-3% процессорного времени и требует много работы.Я заметил, что если я увеличу задержку между уведомлениями примерно до 250 мс, Galaxy S начнет работать так, как я и ожидал (stddev падает примерно до 6-7).К сожалению, 250 мс - это далеко не пригодная задержка для аудио-визуализации.
После ввода всего этого я не могу не чувствовать, что это лучше, относится к какому-то сообщению об ошибке, но опять же, это Samsung, о котором мы говоримо, и мы знаем, что у них нет сообщений об ошибках в интернет-андроиде : (
Альтернативы, идеи и опыт приветствуются.