Воспроизведение звука с микрофона андроид

Воспроизведение звука с микрофона андроид

Микрофон динамик(трансляция звука)
Версия: 2.0.02

Последнее обновление программы в шапке: 18.04.2021

Краткое описание:
Вывод микрофона через динамики, наушники, гарнитуру.

Описание:
Это приложение может выводить звук через наушники или гарнитуру.
Это приложение выводит звук с микрофона через выбранный динамик.

Звук с микрофона также можно воспроизводить в фоновом режиме.
Вы можете использовать его как микрофон для караоке во время воспроизведения музыки.
Используйте микрофон для презентации во время презентации.
Это приложение имеет функцию переключения выхода динамика.
Вы можете записать ASMR с помощью приложения MIC Speaker.

Создайте свой собственный караоке с мини-микрофоном.

Как использовать мини-микрофон (миниатюрный микрофон).
1. Подключите мини-микрофон к вашему смартфону.
2. Подключите наушники к разъему для мини-микрофона.
3. Выберите приложение Home Headset, режим наушников.
4. Нажмите кнопку микрофона на следующем экране.
Звуковой сигнал с мини-микрофона выводится на наушники.
Даже без мини-микрофона он работает как гарнитура (наушники с микрофоном).

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

Вывод звука через гарнитуру Bluetooth или динамик Bluetooth.

Русский интерфейс: Да
Требуется Android: 4.0 и выше.
Разработчик: eonsoft21 Google Commerce Ltd
Google Play: http://play.google.com/store/apps/details?id=com.eonsoft.micspeaker
Имя пакета: com.eonsoft.micspeaker.2002

Скачать:
Версия: 2.0.02 Микрофон.динамик.v.2.0.02.b.apk ( 3.82 МБ )
(без рекламы)

Сообщение отредактировал Vadimluk1 — 18.04.21, 23:43

Источник

Полный список

— пишем звук с помощью MediaRecorder

Воспроизводить звук мы научились, теперь попробуем его записать. Для этого можно использовать MediaRecorder. Этот же класс используется и для записи видео, но об этом поговорим в следующих уроках. Пока нас интересует звук.

Чтобы MediaRecorder записал для вас звук, он должен знать:
— источник звука
— формат записи
— аудио-кодек
— имя файла

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

В хелпе есть пример, в котором используется кодек AMR-NB и формат 3GPP. Их я и буду использовать в своем примере.

Напишем простое приложение, которое будет записывать звук с микрофона и даст возможность прослушать то, что записали.

Project name: P1291_MediaRecorderAudio
Build Target: Android 2.3.3
Application name: MediaRecorderAudio
Package name: ru.startandroid.develop.p1291mediarecorderaudio
Create Activity: MainActivity

Добавим строки в strings.xml:

Рисуем экран main.xml:

Две верхние кнопки стартуют и останавливают запись, две нижние – воспроизведение записанного.

В onCreate задаем имя файла, куда будет записываться звук.

Так же, как и для MediaPlayer, в хелпе есть подробная схема состояний и действий для MediaRecorder. Советую ознакомиться.

В recordStart мы избавляемся от старого рекордера. Затем удаляем файл для записи, если он уже существует. Далее создаем и настраиваем рекордер используя ряд методов.

setAudioSource. Указываем источник звука – микрофон (MIC). Кроме микрофона есть еще несколько источников:

VOICE_CALL — звук при голосовом разговоре по телефону
VOICE_DOWNLINK — только входящая часть VOICE_CALL
VOICE_UPLINK — только исходящая часть VOICE_CALL
CAMCORDER — микрофон, связанный с веб-камерой
VOICE_RECOGNITION — с микрофона будет записываться исходный аудио поток без преобразований, чтобы получить максимальное качество. Используется для распознавания речи
VOICE_COMMUNICATION – аудио поток с микрофона будет «заточен» под VoIP

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

setOutputFormat. Указываем формат – 3GPP (THREE_GPP). Остальные форматы можно посмотреть здесь.

setAudioEncoder. Указываем кодек для сжатия аудио — AMR_NB. Остальные кодеки можно посмотреть здесь.

setOutputFile. Указываем имя файла, в который будет вести запись.

После всех настроек вызываем метод prepare, который подготовит рекордер к записи и стартуем запись методом start.

В recordStop останавливаем запись методом stop. После этого метода необходимо заново настроить рекордер, если вы снова хотите его использовать. Просто снова вызвать start не получится. На схеме это показано. Кстати, метод reset также сбрасывает все настройки рекордера и после него необходимо заново указывать источник. формат, кодек, файл. Но объект новый создавать необязательно.

В playStart и playStop стартуем и останавливаем воспроизведение записанного файла. Тут ничего нового для нас, все это обсуждалось в Уроке 126.

В методе releaseRecorder мы освобождаем все ресурсы рекордера методом release. После этого объект уже нельзя использовать и необходимо создавать и настраивать новый.

В манифесте необходимо прописать права на запись звука и работу с SD:

После запуска приложения вы сможете записать звук с микрофона и прослушать его.

Распишу еще несколько интересных методов.

setAudioChannels – можно задать режим записи 1 (моно) или 2 (стерео)

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

setMaxDuration позволяет указать максимальную длительность записи. По достижении этого времени (в мсек), запись остановится, а слушатель, указанный в MediaRecorder.OnInfoListener, получит код what = MEDIA_RECORDER_INFO_MAX_DURATION_REACHED.

setMaxFileSize позволяет указать максимальный размер файла. По достижении указанного размера (в байтах), запись остановится, а слушатель, указанный в MediaRecorder.OnInfoListener, получит код what = MEDIA_RECORDER_INFO_MAX_FILESIZE_REACHED.

Разумеется, эти методы надо вызывать перед вызовом prepare

На следующем уроке:

— пишем звук с помощью AudioRecorder

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Создание собственного Android-диктофона с помощью Kotlin

Мультимедийный фреймворк Android поддерживает запись и воспроизведение аудио. В этой статье я покажу, как разработать простое приложение для звукозаписи, которое будет записывать аудио и сохранять его в локальном хранилище Android-устройства с помощью MediaRecorder из Android SDK.

Вы также узнаете, как запросить разрешения у пользователя в режиме реального времени и как работать с локальным хранилищем Android-устройства.

Создание пользовательского интерфейса

Сперва нам нужно создать интерфейс для звукозаписи. Это простой layout с тремя кнопками, которые будут использоваться для запуска, приостановки/возобновления и остановки записи.

Запрос требуемых разрешений

После создания пользовательского интерфейса мы можем начать использовать MediaRecorder для реализации основной функциональности нашего приложения. Но сначала нам нужно запросить необходимые разрешения для записи аудио и доступа к локальному хранилищу. Cделаем мы это это с помощью нескольких простых строк кода в нашем файле AndroidManifest.xml :

Также нужно проверить, одобрил ли пользователь разрешения, прежде чем мы сможем использовать наш MediaRecorder . Сделаем это в Activity MainActivity.kt :

Примечание: позже эти строки кода будут перемещены в OnClickListener кнопки начала записи аудио, чтобы мы могли убедиться, что MediaRecorder не будет запущен без необходимых разрешений.

Запись и сохранение аудио

Добавление OnClickListeners

Добавим слушатели к кнопкам, чтобы они реагировали на пользовательские события. Как я упоминал ранее, проверка на наличие необходимых разрешений будет добавлена в OnClickListener кнопки начала записи аудио:

Настройка MediaRecorder

Далее нам нужно указать путь для сохранения аудио и настроить MediaRecorder.

Мы берём путь к корню нашего внешнего хранилища и добавляем в него имя нашей записи и тип файла. После этого мы создаём объект MediaRecorder и определяем источник звука, аудиокодер, формат и файл для записи.

Запись и сохранение аудио

Код, используемый для запуска MediaRecorder , определяется в OnClickListener кнопки начала записи аудио:

Как видите, нужно вызвать функцию prepare , прежде чем мы сможем начать запись. Мы также встраиваем вызов в блок try-catch, чтобы приложение не сломалось при сбое функции prepare .

OnClickListeners кнопки остановки записи очень похож на код выше.

Здесь мы проверяем, работает ли в данный момент MediaRecorder , прежде чем мы остановим запись, потому что наше приложение сломается, если метод stop будет вызван, в то время как MediaRecorder не будет запущен. После этого мы меняем переменную состояния на false , чтобы пользователь не мог снова нажать кнопку остановки.

Нам осталось определить OnClickListener для кнопки приостановки/возобновления.

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

Наконец, мы можем записать аудио и прослушать его, открыв файл recording.mp3 , который будет сохранён в нашем локальном хранилище. Просто откройте проводник файлов и сделайте поиск по имени файла recording.mp3 .

Исходный код

Вот полный исходный код нашего приложения:

Заключение

Теперь вы знаете, как работает MediaRecorder , как запрашивать разрешения в режиме реального времени и почему это важно делать. Вы также узнали о локальном хранилище вашего устройства Android и о том, как хранить в нём данные.

Более сложная версия этого приложения, в которой есть некоторые дополнительные функции, такие как воспроизведение ваших записей с помощью MediaPlayer , доступна на Github.

Источник

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 года, но вполне актуален.

Источник