Работа со звуками android

Кто сказал Мяу? — работаем со звуками Му, Мяу, Гав

Напишем программу, которая поможет определить, кто-же сказал Мяу? Меня всегда интересовал данный вопрос.

Подготовим заранее картинки различных животных и вставим их в папку res/drawable. Создадим макет приложения. Можно использовать ImageView или ImageButton. Я использовал оба варианта для Java и Kotlin.

Положим подготовленные аудио-файлы с голосами животных в директорию assets. По умолчанию в проекте такой папки нет. Выбираем File | New | Folder | Assets Folder. В диалоговом окне оставляем всё без изменений и нажимаем кнопку Finish. Файлы, лежащие в этой папке, считайте тоже ресурсами. Но они имеют свои особенности, в частности вы можете создавать свою структуру подпапок.

Переходим к программной части. Нам надо создать объект SoundPool, загрузить в него аудио-файлы из папки assets методом load().

Зададим максимальное количество одновременно проигрываемых потоков — 3.

При нажатии на кнопку (или картинку) будем проигрывать нужный звук. В варианте для Java остался устаревший код, в Kotlin-коде оставил только правильный вариант. Но не стал делать защиту от поворота, просто смотрите на Java-код и доработайте самостоятельно.

При загрузке файлов метод load() возвращает идентификатор soundID, который сохраняем для дальнейшего использования. Объявим для каждого звука отдельную переменную, если же звуков много лучше завести для этого ассоциативный массив.

Файловый дескриптор AssetFileDescriptor для файла из директории assets получаем с помощью метода openFd(), принимающего в качестве параметра имя файла. Если файл не найден или не может быть открыт, то выводим сообщение и в качестве soundID возвращаем -1.

По нажатию кнопки вызываем метод playSound(), передавая ему нужный идентификатор звука. В методе проверяем этот идентификатор. Если файл не был найден, то метод loadSound() возвращает -1, а если метод load() класса SoundPool не смог загрузить файл, то soundID будет равен 0, поэтому проверяем, что SoundID > 0, что означает, что файл был успешно загружен. Если же все хорошо, то вызываем метод play().

В версии Android 5.0 конструктор класса SoundPool является устаревшим. В коде использовано условие if с проверкой версии системы на устройстве, а также использованы аннотации, чтобы студия не ругалась на устаревший метод. Про аннотации мы поговорим в другой статье, пока воспринимайте их как подсказку-предупреждение при написании кода, чтобы выбрать правильный вариант.

Программа держит загруженные звуки в памяти. Если они вам не нужны, то нужно освободить ресурсы. Я сделал это в методе onPause(), соответственно загрузку пришлось перенести в onResume().

Запустим программу и выясним, так кто-же сказал Мяу?

Один из читателей захотел выводить звук не через щелчок, а нажатие на кнопку. А когда палец открывается от экрана, то звук должен прекращаться. Получился интересный эффект, который мы нашли сообща. Код для кнопки с коровой (предыдущий код лучше убрать):

При воспроизведении звука мы получаем его идентификатор, используемый для остановки воспроизведения.

Источник

Программирование звука в Android — SoundPool и MediaPlayer

Перед любым разработчиком, занимающимся созданием красивых интерактивных приложений, рано или поздно встает вопрос об использовании мультимедийных возможностей телефона. Для работы со звуком в Android программисты активно используют две библиотеки. Первая из них предоставляет класс SoundPool, вторая — MediaPlayer.

Класс SoundPool удобно использовать для проигрывания коротких аудиоклипов. С его помощью можно проигрывать несколько звуков одновременно, при этом размер звукового файла не должен превышать 1 Mb. Класс MediaPlayer лучше подходит для воспроизведения долгих аудио и видеороликов.

Android управление звуком

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

Как проиграть звук через SoundPool

Напишем приложение, которое будет проигрывать звук при касании экрана. Создадим новый проект с именем CrazySong, пакет назовем
ru.mobilab.crazysong, в качестве главной Activity укажем CrazySongActivity.

Приведем main.xml к виду

Давайте рассмотрим последовательность действий, которую необходимо выполнить для того, чтобы воспроизвести звуковой файл. Прежде всего мы должны создать объект soundPool. Его конструктор имеет несколько параметров. Первый параметр задает максимальное число одновременно проигрываемых файлов. Второй параметр задает тип аудиопотока. В большинстве случаев здесь подойдет значение soundPool STREAM_MUSIC, хотя возможно использование и других аудиопотоков. Их назначение довольно очевидно. (STREAM_ALARM, STREAM_DTMF, STREAM_NOTIFICATION, STREAM_RING,STREAM_SYSTEM, STREAM_VOICE_CALL). Третий параметр задает sample-rate. В настоящее время он ни на что не влияет, поэтому здесь устанавливаем 0.

После того, как мы создали объект для SoundPool, с помощью setOnLoadCompleteListener добавим к нему OnLoadCompleteListener, который будет отслеживать завершение загрузки файлов. В качестве параметров метод onLoadComplete принимает объект SoundPool, номер загруженного сэмпла и статус завершения операции. В случае, если все прошло успешно, статус равен нулю.

Прежде чем проигрывать звуковые файлы их необходимо загрузить в SoundPool. Сделать это можно с помощью метода load. Метод имеет несколько реализаций, различающихся набором параметров и источником, поставляющим звуковые файлы. Можно загружать файлы из папки asset, можно из APK ресурсов, можно из файла, указав к нему путь, можно из FileDescriptor. Мы будем рассматривать ситуацию, когда звуковые сэмплы входят в состав APK пакета, то есть лежат в папке res/raw вашего проекта. Для загрузки нам понадобятся три параметра: ссылка на контекст из которого мы получаем доступ к ресурсам программы (в большинстве случаев подойдет this), ссылка на ресурс, полученная через объект R, и приоритет, который пока ни на что не влияет, и в документации рекомендуется устанавливать значение 1. Загруженные ресурсы можно выгрузить с помощью методов unload, если требуется удалить один сэмпл, и release — если нужно полностью очистить SoundPool.

Для проигрывания сэмпла используется метод play, имеющий следующие параметры:

• soundID переменная с номером сэмпла. Этот номер возвращается в результате выполнения метода load.
• leftVolume значение громкости левого канала (от 0.0 до 1.0)
• rightVolume значение громкости правого канала (от 0.0 до 1.0)
• priority приоритет потока (0 — самый низкий приоритет)
• loop сколько раз нужно повторить сэмпл (0 не повторять, -1 — зациклить)
• rate скорость воспроизведения (может изменяться от 0.5 до 2.0, 1 — нормальная скорость)

В результате выполнения метода play возвращается номер streamID (или 0 в случае ошибки), который можно использовать для управления воспроизведением. Например это значение используется при вызове методов pause и resume, stop, setVolume, setLoop. Если число максимально проигрываемых файлов превышено, то вызов очередного метода play приведет к завершению воспроизведения одного из проигрываемых в данный момент сэмплов.

Код нашего класса приведен ниже
package ru.mobilab.crazysong;

SoundPool и утечка памяти

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

но похоже, что этот метод не решает проблему вAndroid 2.1. Если Вы располагаете информацией об этой проблеме и ее решении, просьба отписаться в комментариях.

Воспроизведение фоновой музыки в Android с помощью MediaPlayer

SoundPool отлично подходит для озвучивания различных игровых событий: выстрелов, взрывов, реплик. Однако для проигрывания фоновой музыки нужно использовать класс MediaPlayer. Метод create этого класса имеет два параметра: контекст и ссылку на ресурс или URI адрес музыкального файла. Для запуска/паузы/остановки воспроизведения служат методы start(), pause() и stop() соответственно. Все просто.

В случае, если Вы собираетесь подгружать файл из интернета, последовательность действий будет немного другая. Метод create использовать не нужно. Источник аудиоданных задается с помощью метода setDataSource, после которого нужно вызвать метод prepare(), блокирующий выполнение потока до тех пор, пока медиаплеер не будет готов к воспроизведению музыки. Метод prepareAsync() выполняет те же действия в асинхронном режиме, то есть не блокирует вызвавший его поток. В случае использования prepareAsync нужно использовать OnPreparedListener для определения момента, когда MediaPlayer готов к проигрыванию файла. Заметим, что при использовании метода create метод prepare вызывать не нужно, поскольку он вызывается внутри create.

Остался еще один актуальный вопрос: как определить, что воспроизведение файла закончилось? Для этой цели служит функция обратного вызова onCompletion. Чтобы привязать ее к нашему медиаплееру нужно выполнить следующий код:

Вот собственно и все. Воспроизведение звука не такая уж и сложная тема. Архив с проектом можетескачать здесь.

Источник

Особенности обработки аудио в ОС Android

И как с ними бороться

Подумайте, какие ассоциации вызывает у вас операционная система Google Android? Наверняка, одной из первых в голове всплыла «распространенность», «популярность». Или, при подобающем настроении, такое словосочетание как «зоопарк устройств». Что и говорить, выбор в пользу Android уже давным-давно сделали почти все известные разработчики мобильных гаджетов.

В крупных компаниях этот шаг знаменует собой начало большого пути для подразделения R&D (Research and Development). Ведь базовые возможности Android (по крайней мере, до релиза Lollipop) были весьма скромны и могли устроить только завсегдатаев XDA Developers, которые все необходимое и сами могут дописать. В поисках примеров можно даже не уходить в дебри Android. Скажем, аппараты с поддержкой нескольких SIM-карт уже давно стали самым обычным явлением на рынке. А API для работы с ними был официально добавлен только в Google Android 5.1.

Сегодня мы подробно рассмотрим еще одну сторону ОС, которой разработчики Google Android не уделяют достойного внимания — работу со звуком. Зачем, в принципе, нужен звук на телефоне? В первую очередь, чтобы воспроизводить звонок. С этой задачей мобильные устройства справляться уже научились. Было бы здорово также вставить какой-нибудь аудиоплеер. и здесь компания Google без особых раздумий перекладывает все на производителей устройств. Беспроводное проигрывание через Bluetooth или динамики мобильных устройств зависит от ряда дополнительных факторов, требующих отдельного изучения, поэтому в данной статье мы рассмотрим, как обстоят дела с воспроизведением аудио исключительно через разъем для наушников.

До выхода Android L операционная система поддерживала «из коробки» только PCM-аудио с частотой дискретизации 44,1 или 48 кГц. К этому общему знаменателю по умолчанию приводится весь пропускаемый через систему аудиопоток. Исправление ситуации проходит на уровне конкретных производителей, которые устанавливают собственные ЦАП и пишут для них софт. Это могут позволить себе лишь крупные компании. Приобретая такое недешевое устройство как смартфон, хочется услышать адекватный по стоимости аудиочип, но на сегодняшний день это является скорее исключением из правил — большинство моделей ограничиваются лишь тем, что включено в однокристальную систему. А это значит, что воспроизведение происходит с принудительной конвертацией звука в формат, описанный в начале абзаца.

Любой, кто хотя бы немного знаком с обработкой звука, знает, что всякое препятствие на его пути чревато самыми тяжелыми последствиями. При желании проследить всю обработку звука в ОС Android можно через исходный код. Уже при поверхностном изучении настороженность вызывают следующие моменты:

1. Для принудительной конвертации в нативный формат применяются как минимум целых три конвертера — в audioflinger, speex и webrtc. Здесь никакого прогресса не наблюдается с самых ранних версий, Google лишь исправляет баги.
2. Слишком высокий тайминг в аудиосервере Android (audioflinger/libstagefright) при большом числе потоков.
3. Программная регулировка громкости — критичный для аудиофилов аспект, с которым, увы, ничего не поделаешь в принципе.
4. Колоссальные проблемы с поддержкой ALSA-драйверов (Advanced Linux Sound Architecture). Этот вопрос решается на уровне производителей устройств. Некоторые из них уже предлагают удачные решения, например, Sony и HTC.

Помимо R&D-отделов больших компаний, над улучшением звука Android активно работают энтузиасты, разрешающие порой чуть ли не безвыходные проблемы. Плоды этих титанических трудов можно оценить на пресловутом XDA Developers.

Здесь работает общее правило: чем ниже уровень, на котором производятся улучшения, тем эффективней будет результат. Материнские платы компьютеров легко вмещают всякие разновидности «high definition audio», способные удовлетворить не очень щепетильного пользователя. Что же касается современных мобильных устройств, то их размеры создают для реализации качественного звука гораздо более серьезные ограничения.

Тем не менее, прогресс в звуковой составляющей современных смартфонов очевиден. Как это ни удивительно, даже чипсетные кодеки порой играют неплохо, например, ЦАП Hexagon, устанавливаемые в SoC Qualcomm Snapdragon. Что касается однокристальных систем, менее выдающихся в плане звука (модели Samsung Exynos, Mediatek MTK), то их производители сейчас нередко устанавливают сторонние ЦАП. К сожалению, при таком подходе обычно игнорируется сопроводительная документация, что приводит к затруднениям на более высоких уровнях.

А выше «железа» у нас прописано ядро Linux — база, на которой функционирует ОС Android. Здесь находится все, что обеспечивает работу аппаратной начинки. Конкретно за звук отвечает ALSA — Advanced Linux Sound Architecture. Пионером в реализации ALSA стала компания Samsung, а вообще в ранних устройствах на базе Android эта архитектура еще не поддерживалась, поскольку сама Google еще не пришла к необходимости единообразия на данном уровне разработки.

Сама по себе архитектура ALSA является весьма оригинальной, что отчасти объясняет проблема в создании низкоуровневого ПО. Даже на написание даже простого драйвера требуется много времени. К тому же, в отличие от десктопных систем, у смартфонов есть своя специфика. Поскольку мы имеем дело с телефоном, обязательна реализация голосовой связи. Кроме того, требуется грамотное управление питанием — об автономной работе Android-устройств лишний раз и говорить нечего. Наконец, учитывая ограниченные ресурсы прикладного ЦП, встает вопрос о декодировании популярных форматов другими аппаратными средствами.

Типичный сценарий работы над ALSA-драйверами сегодня выглядит следующим образом. Поставщик SoC или кодека предоставляет производителю устройства некую «рыбу» в комплекте с многотомной документацией, при виде которой у Linux-сообщества потекли бы слюнки. Но работникам R&D-отделов производителя такой энтузиазм, мягко говоря, не свойственен. В результате чего пользователи получают ПО, где взамен реализованных возможностей железа предлагаются лишь бесчисленные баги и вообще полнейшие нелепости.

В качестве примера можно привести компанию Qualcomm, которая никакой документацией с аудиторией не делится. Но хотя бы выкладывает исходный код драйверов на своем сайте codeaurora.org. С другими поставщиками чипов ситуация тоже непростая. Даже такие либеральные в этом плане компании как Texas Instruments или Intel, публикующие все спецификации своих устройств еще до начала поставок, иной раз хранят молчание, когда речь заходит о звуке.

Что касаются производителей «второго эшелона» (как правило, многочисленных и малоизвестных компаний из Китая), то в соответствии с лицензией GPL они не обнародуют исходный код ядра вообще. С этической точки зрения выглядит это весьма скверно: на основе открытого кода Linux создается по сути закрытый, засекреченный продукт.

Как же свести весь этот «зоопарк» к общему знаменателю, чтобы любой обладатель Android-устройства мог получить качественный звук? Интерфейс ALSA-драйверов един, и, если доступны их исходные файлы, можно попытаться самостоятельно улучшить качество звука, чтобы использовать возможности устройства на 100%.

Поскольку взаимодействие осуществляется на уровне ядра, для всех нововведений потребуется наличие рут-доступа. Это позволит обойти верхние уровни аудиосистемы Android и взаимодействовать с ALSA-драйверами напрямую. Что и делает программа, которую мы задействуем для сравнительного тестирования аудиотрактов.

Источник