OpenSL — плохой поиск с помощью объекта аудиоплеера

Я пишу приложение для Android, которое должно иметь возможность искать определенные точки в большом аудиофайле mp3 (~ 90 минут) с хорошей точностью.

В настоящее время я использую подход OpenSL с объектом аудиоплеера с источником данных URI, который указывает файл mp3 и информацию MIME.

Чтобы проверить это, я использую интерфейс SLSeekITF на проигрывателе для поиска определенных точек (указанных в миллисекундах). Однако я считаю, что производительность поиска плохая и непоследовательная. Часто звук отличается на 1-10 секунд от того, где он должен быть. Иногда впереди, иногда сзади. Производительность немного лучше при использовании более коротких mp3-файлов, но далеко не достаточно.

Режимы поиска («точный» и «быстрый») не имеют никакого значения для SLSeekITF.

На других платформах я могу получить очень точную позицию поиска ‹ 50 мс, что едва заметно, поэтому я знаю, что это возможно.

-Кто-нибудь знает, как повысить точность аудиоплеера OpenSL? -Есть ли известные проблемы с этой реализацией? -Есть ли другие декодеры mp3 с более высокой производительностью?

Спасибо


person rmigneco    schedule 22.08.2013    source источник


Ответы (1)


Я также разместил этот вопрос в группе Google NDK: https://groups.google.com/forum/#!topic/android-ndk/rzVr3A0DjBs

Хотя я никогда не получал официального ответа от кого-либо из Google, отзывы, которые я получил, похоже, указывают на то, что Media Player и/или воспроизведение звука из URI с помощью OpenSL ES, как известно, содержат ошибки.

В итоге я решил эту проблему, используя сторонний mp3-декодер с возможностью поиска и объект Buffer Queue Audio Player в OpenSL ES для воспроизведения аудиосэмплов.

Вряд ли это легко сделать, но это работает.

person rmigneco    schedule 30.09.2013