Android как проиграть звук

Класс SoundPool

Основное отличие класса SoundPool от класса MediaPlayer — поддержка одновременного проигрывания нескольких аудиопотоков, что широко используется в играх.

Обычно SoundPool используют для проигрывания маленьких аудиоклипов. SoundPool может играть несколько звуков одновременно. Звуки также можно повторять (зациклить). В этом случае для остановки проигрывания нужно явно вызывать метод остановки. Размер файла, который может проиграть SoundPool не должен превышать 1 мегабайт.

Поддерживаются файлы практически всех популярных форматов: mp3, ogg, wav, aac, 3gp, flac. После загрузки файлы перекодируются (в 16-bit PCM моно или стерео) для упрощения воспроизведения.

Можно управлять скоростью воспроизведения аудио файла. Скорость 1,0 означает воспроизведение звука в исходном виде, 2,0 — воспроизведение в два раза быстрее, а 0,5 в два раза медленнее. Диапазон скорости воспроизведения составляет от 0,5 до 2,0.

Можно программно задать количество аудио потоков, проигрываемых одновременно. Если максимальное число потоков будет превышено, автоматически остановится поток с самым низкий приоритетом. При наличии нескольких потоков с тем же низким приоритетом, будет выбран старейший из них. В случае, если приоритет нового потока ниже, чем все активные потоки, новый звук не будет проигран. Ограничение максимального числа потоков помогает снизить загрузку процессора.

Конструктор класса SoundPool

• maxStreams — максимальное количество потоков, который могут воспроизводится одновременно
• streamType — тип аудиопотока, это константа из класса AudioManager. Здесь чаще всего используется AudioManager.STREAM_MUSIC.
• srcQuality — качество кодирования. Сейчас этот параметр не используется, поэтому всегда будем передавать 0.

В API 21 конструктор считается устаревшим. Смотри ниже.

Методы

Загрузить аудио файлы в SoundPool можно с помощью четырёх методов:

Загрузка из папки assets. Нужно знать путь к файлу. AssetManager — класс, предоставляющий доступ к файлам в директории assets. Получить экземпляр класса для данного приложения можно методом getAssets(). AssetFileDescriptor — файловый дескриптор для файла из директории assets.

Загрузка файла по идентификатору ресурса. Звуковые файлы могут находиться в каталоге res/raw, и соответственно идентификатор будет R.raw.sound.

Загрузка файла из указанного пути.

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

В каждом методе мы передаём priority — приоритет файла. Методы возвращают идентификатор загруженного звука, который позже используется для воспроизведения.

Загрузка файлов происходит асинхронно, то есть после вызова метода load() файл не сразу будет доступен для воспроизведения, так как необходимо время для его загрузки и перекодирования. Для того чтобы отследить окончание загрузки нужно обработать событие OnLoadCompleteListener. Для этого устанавливаем обработчик события с помощью метода void setOnLoadCompleteListener(SoundPool.OnLoadCompleteListener listener), где SoundPool.OnLoadCompleteListener — это интерфейс с единственным методом void onLoadComplete(SoundPool soundPool, int sampleId, int status), который вызывается когда файл загружен. Здесь sampleId — идентификатор загруженного файла (то есть то, что вернул метод load()), а status — статус загрузки (значение 0 обозначает успешную загрузку).

Метод для проигрывания звука

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

Метод возвращает целое число int, которое используется в других методах в качестве параметра streamID.

Возобновить приостановленный поток (если поток был не на паузе, то метод не даст никакого результата)

Установка количество повторов для потока

Установка приоритета для потока

Установка скорости для потока

Установка громкости для потока

Приостановить все активные потоки

Возобновить все потоки

Удаляет звук из SoundPool. Метод возвращает true, если операция прошла успешно, и false, если такого SoundID не существует

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

Пример

Добавим на форму две кнопки, а также звуковой файл в папку ресурсов res/raw. Образцы бесплатных звуков можно взять в разделе Звуки.

Кнопку управления громкостью телефона можно настроить для управления громкости звуков:

SoundPool.Builder (API 21)

В Android 5.0 (API 21) вызов конструктора считается устаревшим. На смену ему пришёл класс SoundPool.Builder. Ниже приводится код из одного проекта.

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

Источник

Программирование звука в 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 и звук: как делать правильно

В статье рассматривается архитектура и API для создания приложений, воспроизводящих музыку. Мы напишем простое приложение, которое будет проигрывать небольшой заранее заданный плейлист, но «по-взрослому» — с использованием официально рекомендуемых практик. Мы применим MediaSession и MediaController для организации единой точки доступа к медиаплееру, и MediaBrowserService для поддержки Android Auto. А также оговорим ряд шагов, которые обязательны, если мы не хотим вызвать ненависти пользователя.

В первом приближении задача выглядит просто: в activity создаем MediaPlayer, при нажатии кнопки Play начинаем воспроизведение, а Stop — останавливаем. Все прекрасно работает ровно до тех пор, пока пользователь не выйдет из activity. Очевидным решением будет перенос MediaPlayer в сервис. Однако теперь у нас встают вопросы организации доступа к плееру из UI. Нам придется реализовать binded-сервис, придумать для него API, который позволил бы управлять плеером и получать от него события. Но это только половина дела: никто, кроме нас, не знает API сервиса, соответственно, наша activity будет единственным средством управления. Пользователю придется зайти в приложение и нажать Pause, если он хочет позвонить. В идеале нам нужен унифицированный способ сообщить Android, что наше приложение является плеером, им можно управлять и что в настоящий момент мы играем такой-то трек из такого-то альбома. Чтобы система со своей стороны подсобила нам с UI. В Lollipop (API 21) был представлен такой механизм в виде классов MediaSession и MediaController. Немногим позже в support library появились их близнецы MediaSessionCompat и MediaControllerCompat.

Следует сразу отметить, что MediaSession не имеет отношения к воспроизведению звука, он только об управлении плеером и его метаданными.

MediaSession

Итак, мы создаем экземпляр MediaSession в сервисе, заполняем его сведениями о нашем плеере, его состоянии и отдаем MediaSession.Callback, в котором определены методы onPlay, onPause, onStop, onSkipToNext и прочие. В эти методы мы помещаем код управления MediaPlayer (в примере воспользуемся ExoPlayer). Наша цель, чтобы события и от аппаратных кнопок, и из окна блокировки, и с часов под Android Wear вызывали эти методы.

Полностью рабочий код доступен на GitHub (ветка master). В статьи приводятся только переработанные выдержки из него.

Для доступа извне к MediaSession требуется токен. Для этого научим сервис его отдавать

и пропишем в манифест

MediaController

Теперь реализуем activity с кнопками управления. Создаем экземпляр MediaController и передаем в конструктор полученный из сервиса токен.

MediaController предоставляет как методы управления плеером play, pause, stop, так и коллбэки onPlaybackStateChanged(PlaybackState state) и onMetadataChanged(MediaMetadata metadata). К одному MediaSession могут подключиться несколько MediaController, таким образом можно легко обеспечить консистентность состояний кнопок во всех окнах.

Наша activity работает, но ведь идея исходно была, чтобы из окна блокировки тоже можно было управлять. И тут мы приходим к важному моменту: в API 21 полностью переделали окно блокировки, теперь там отображаются уведомления и кнопки управления плеером надо делать через уведомления. К этому мы вернемся позже, давайте пока рассмотрим старое окно блокировки.

Как только мы вызываем mediaSession.setActive(true), система магическим образом присоединяется без всяких токенов к MediaSession и показывает кнопки управления на фоне картинки из метаданных.

Однако в силу исторических причин события о нажатии кнопок приходят не напрямую в MediaSession, а в виде бродкастов. Соответственно, нам надо еще подписаться на эти бродкасты и перебросить их в MediaSession.

MediaButtonReceiver

Для этого разработчики Android любезно предлагают нам воспользоваться готовым ресивером MediaButtonReceiver.

Добавим его в манифест

MediaButtonReceiver при получении события ищет в приложении сервис, который также принимает «android.intent.action.MEDIA_BUTTON» и перенаправляет его туда. Поэтому добавим аналогичный интент-фильтр в сервис

Если подходящий сервис не найден или их несколько, будет выброшен IllegalStateException.

Теперь в сервис добавим

Метод handleIntent анализирует коды кнопок из intent и вызывает соответствующие коллбэки в mediaSession. Получилось немного плясок с бубном, но зато почти без написания кода.

На системах с API >= 21 система не использует бродкасты для отправки событий нажатия на кнопки и вместо этого напрямую обращается в MediaSession. Однако, если наш MediaSession неактивен (setActive(false)), его пробудят бродкастом. И для того, чтобы этот механизм работал, надо сообщить MediaSession, в какой ресивер отправлять бродкасты.
Добавим в onCreate сервиса

На системах с API Так это выглядит

Android 4.4

MIUI 8 (базируется на Android 6, то есть теоретически окно блокировки не должно отображать наш трек, но здесь уже сказывается кастомизация MIUI).

Уведомления

Однако, как ранее упоминалось, начиная с API 21 окно блокировки научилось отображать уведомления. И по этому радостному поводу, вышеописанный механизм был выпилен. Так что теперь давайте еще формировать уведомления. Это не только требование современных систем, но и просто удобно, поскольку пользователю не придется выключать и включать экран, чтобы просто нажать паузу. Заодно применим это уведомление для перевода сервиса в foreground-режим.

Нам не придется рисовать кастомное уведомление, поскольку Android предоставляет специальный стиль для плееров — Notification.MediaStyle.

Добавим в сервис два метода

И добавим вызов refreshNotificationAndForegroundStatus(int playbackState) во все коллбэки MediaSession.

Android 4.4

Android 7.1.1

Android Wear

Started service

В принципе у нас уже все работает, но есть засада: наша activity запускает сервис через binding. Соответственно, после того, как activity отцепится от сервиса, он будет уничтожен и музыка остановится. Поэтому нам надо в onPlay добавить

Никакой обработки в onStartCommand не надо, наша цель не дать системе убить сервис после onUnbind.

А в onStop добавить

В случае, если к сервису привязаны клиенты, stopSelf ничего не делает, только взводит флаг, что после onUnbind сервис можно уничтожить. Так что это вполне безопасно.

ACTION_AUDIO_BECOMING_NOISY

Продолжаем полировать сервис. Допустим пользователь слушает музыку в наушниках и выдергивает их. Если эту ситуацию специально не обработать, звук переключится на динамик телефона и его услышат все окружающие. Было бы хорошо в этом случае встать на паузу.
Для этого в Android есть специальный бродкаст AudioManager.ACTION_AUDIO_BECOMING_NOISY.
Добавим в onPlay

В onPause и onStop

И по факту события встаем на паузу

Android Auto

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

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

Исходный код выложен на GitHub (ветка MediaBrowserService).

Прежде всего надо указать в манифесте, что наше приложение совместимо с Android Auto.
Добавим в манифест

Здесь automotive_app_desc — это ссылка на файл automotive_app_desc.xml, который надо создать в папке xml

Преобразуем наш сервис в MediaBrowserService. Его задача, помимо всего ранее сделанного, отдавать токен в Android Auto и предоставлять плейлисты.

Поправим декларацию сервиса в манифесте

Во-первых, теперь наш сервис экспортируется, поскольку к нему будут подсоединяться снаружи.

И, во-вторых, добавлен интент-фильтр android.media.browse.MediaBrowserService.

Меняем родительский класс на MediaBrowserServiceCompat.

Поскольку теперь сервис должен отдавать разные IBinder в зависимости от интента, поправим onBind

Имплементируем два абстрактных метода, возвращающие плейлисты

И, наконец, имплементируем новый коллбэк MediaSession

Здесь mediaId — это тот, который мы отдали в setMediaId в onLoadChildren.

Плейлист

Трек

UPDATE от 27.10.2017: Пример на GitHub переведен на targetSdkVersion=26. Из релевантных теме статьи изменений необходимо отметить следующее:

• android.support.v7.app.NotificationCompat.MediaStyle теперь deprecated. Вместо него следует использовать android.support.v4.media.app.NotificationCompat.MediaStyle. Соответственно, больше нет необходимости использовать android.support.v7.app.NotificationCompat, теперь можно использовать android.support.v4.app.NotificationCompat
• Метод AudioManager.requestAudioFocus(OnAudioFocusChangeListener l, int streamType, int durationHint) теперь тоже deprecated. Вместо него надо использовать AudioManager.requestAudioFocus(AudioFocusRequest focusRequest). AudioFocusRequest — новый класс, добавленный с API 26, поэтому не забывайте проверять на API level.
  Создание AudioFocusRequest выглядит следующим образом

Теперь запрашиваем фокус

Разумеется, все вышеописанные изменения вносить необязательно, старые методы работать не перестали.

Вот мы и добрались до конца. В целом тема эта довольно запутанная. Плюс отличия реализаций на разных API level и у разных производителей. Очень надеюсь, что я ничего не упустил. Но если у вас есть, что исправить и добавить, с удовольствием внесу изменения в статью.

Еще очень рекомендую к просмотру доклад Ian Lake. Доклад от 2015 года, но вполне актуален.

Источник