Особенности обработки аудио в ОС 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 можно через исходный код. Уже при поверхностном изучении настороженность вызывают следующие моменты:
- Для принудительной конвертации в нативный формат применяются как минимум целых три конвертера — в audioflinger, speex и webrtc. Здесь никакого прогресса не наблюдается с самых ранних версий, Google лишь исправляет баги.
- Слишком высокий тайминг в аудиосервере Android (audioflinger/libstagefright) при большом числе потоков.
- Программная регулировка громкости — критичный для аудиофилов аспект, с которым, увы, ничего не поделаешь в принципе.
- Колоссальные проблемы с поддержкой 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-драйверами напрямую. Что и делает программа, которую мы задействуем для сравнительного тестирования аудиотрактов.
Источник
Работа с потоковым аудио
Введение
Конструктор
Для создания объекта нужно указать:
| audioSource | Откуда ведётся запись. В нашем случае это MediaRecorder.AudioSource.MIC |
|---|---|
| sampleRateInHz | Частота дискретизации в герцах. Документация утверждает, что 44100Гц поддерживается всеми устройствами |
| channelConfig | Конфигурация каналов. Может быть CHANNEL_IN_MONO или CHANNEL_IN_STEREO . Моно работает везде. Важно: эти константы не совпадают с количеством каналов, которое они обозначают. В этот параметр нельзя передавать 1 или 2. |
| audioFormat | Формат входных данных, более известный как кодек. Может быть ENCODING_PCM_16BIT или ENCODING_PCM_8BIT |
| bufferSizeInBytes | Размер того самого внутреннего буфера. Из него можно считывать аудиопоток. Размер порции считывания не должен превышать эту величину. У этого параметра есть минимально допустимое значение, которое можно получить через getMinBufferSize() . |
При своём создании объект пытается получить нужные ему ресурсы системы. Насколько удачно у него это получилось, можно узнать, вызвав функцию getState() . Если она вернёт STATE_INITIALIZED , то всё нормально, если STATE_UNINITIALIZED — значит, произошла ошибка.
Причин ошибки может быть две: слишком маленький буфер и недопустимый формат. Первого нужно избегать вызовом getMinBufferSize() . Второго, на самом деле, им же.
getMinBufferSize()
Этот статический метод выдаёт минимальный размер внутреннего буфера, при котором объект AudioRecord сможет работать. Параметры имеют тот же смысл, что и для конструктора. Следует заметить, что использование именно этой величины для записи — не лучшая идея. Если система будет ещё чем-то занята, то программа всё равно может не успевать считывать все данные подряд, и в записи будут дырки. Мне встречался совет брать размер в десять раз больше.
Получение списка форматов
Метод getMinBufferSize() имеет приятную особенность — ругаться на недопустимые для данного устройства параметры, возвращая ERROR_BAD_VALUE или ERROR . Это означает, что перебирая все возможные сочетания, можно узнать, какие форматы поддерживает устройство.
Считывание данных
Для получения данных из внутреннего буфера служит метод read() . Он существует в трёх вариантах:
- read(byte[] audioData, int offsetInBytes, int sizeInBytes)
- read(short[] audioData, int offsetInShorts, int sizeInShorts)
- read(ByteBuffer audioBuffer, int sizeInBytes)
Их параметры:
| audioData | массив, в который будут записаны данные |
|---|---|
| audioBuffer | буфер, в который будут записаны данные |
| offsetInBytes / offsetInShorts | индекс, с которого начнётся запись |
| sizeInShorts | размер запрашиваемого блока данных. В байтах для ByteBuffer и byte[] , в коротких целых для short[] |
Если всё нормально, то метод вернёт количество прочитанных байт, если это вариант с ByteBuffer или byte[] , или прочитанных коротких целых для short[] . Если на момент вызова объект не был правильно инициализирован, то выдаст ERROR_INVALID_OPERATION, а если что-то не так с параметрами — ERROR_BAD_VALUE
Важно: метод блокирует вызывающий поток до тех пор, пока не считает запрошенное количество данных. Если во внутреннем буфере их недостаточно, то read() будет ожидать, пока они придут от микрофона. Поэтому метод следует вызывать из отдельного потока, иначе приложение будет висеть.
Подход, отход, фиксация
Чтобы программа могла получать данные от микрофона, нужно указать в файле AndroidManifest,xml соответствующее разрешение:
Чтобы начать запись, нужно вызвать метод startRecording() , а чтобы закончить — stop() . Запускать и останавливать запись можно сколько угодно раз.
После того, как работа с объектом закончена, следует вызвать метод release() . Он освободит все системные ресурсы, захваченные объектом. После этого объект нельзя использовать, а ссылающуюся на него переменную следует установить в null .
Важно: эти три метода, в отличие от упоминавшихся ранее, выбросят IllegalStateException , если их вызвать для неинициализированного (ну и слово. ) объекта или не в том порядке. Поэтому обращаться с ними нужно «аккуратно», т.е. через блок try .
Пример использования
Приведённый ниже класс делает всё то, о чём сказано выше. Кроме того, он посылает зарегистрированным у него Handler -ам сообщения о принятых данных. Эти данные будут обрабатываться в другом потоке, поэтому, чтобы не затереть ещё не обработанные данные новыми, использован циклический буфер.
В коде использован класс AudioFormatInfo . Он представляет собой POJO с тремя полями, описывающими формат записи: sampleRateInHz , channelConfig и audioFormat .
Источник
Tools for Audio Processing in Android Development
During my work as an Android developer I have had to face an unconventional task – the client was interested in the ability of voice processing in real time, that is, on the fly.
Being an amateur sound engineer in my student years I happened to experiment with audio processing and to work with various audio editors on PC. Your voice, at bottom, is a sound, similar to what a musical instrument produces. Thus, what you need is a tool to process an audio signal which you could fully use while developing your Android app.
First of all, you need to understand that studio equipment and a mobile device are completely different things. If to speak about modern software designed to work with audio data, you should know that such applications are quite pricy. Moreover, they require compute capacity of a desk-top computer, which greatly exceeds the capabilities of an average tablet or a phone.
Unfortunately, I wasn’t able to find a turnkey solution for working directly with the voice. However, during my search I got acquainted with some libraries and SDKs that work with audio data and I’d like to tell you about them. Java programming language used in Android development doesn’t allow you to work effectively with audio content, that’s why you’ll mostly have to deal with JNI and C++ code.
SoundTouch Audio Processing Library.
The library is an Open Source project and isn’t an SDK for any specific platform. The developers claim that their tool will work on Windows, Mac OS, Linux & other *nixes, Raspberry Pi, Android, Apple iOS.
The project is a C++ library with quite a limited functionality. The tools for application developers are limited to speeding up/slowing down the tempo and changing the sound pitch. In case of Android development, as noted above, you will have to deal with JNI – to implement C++ code into the project.
One more point is that the library only works with files. The original WAV-file is processed and is saved as a separate one. In order to hear the result of the implemented effects you have to play the newly created file. There is no real-time automatic sound optimization and sound processing on the fly.
Bongiovi DPS SDK.
- sdk.bongiovidps.com
- An exclusively paid license. However, the fee isn’t stated on the site. The given phrase «Please contact us to discuss pricing» suggests quite flexible pricing. Without a license the SDK will work for 10 minutes in demo mode.
The product is a fully-fledged SDK with the ability to be used both in iOS and Android projects. It is a toolkit for those who want to create their own Audio Enhancer.
What is an Audio Enhancer? It is real time processing of the file being played – the application of the common audio effects like «On the street», «In the concert hall» and others, equalizer, dynamic loudness control and so on. To sum up, such tools aim at making the sound being played richer. Naturally, the usage of a quality acoustic system (or headphones) is expected.
Comparing with the tools I dealt with before in terms of sound processing, I would categorize this SDK as a DSP processor. Like a great number of DSP plugins for recently popular mp3 player WinAmp, for example. Now you have a chance to develop one of your own.
In case you have a desire to please the market of media players for portable devices with your product which will have its own sounding and various presets, this SDK will be quite of use to you.
However, it has no pitch-shifters, voice coders or any other sound (including voice) processors.
Essentia.
It’s an open-Source C++ library for audio analysis. It’s not a framework, rather a collection of algorithms wrapped in a cross-platform library compatible with Linux, Mac OS X, Windows, iOS and Android.
It allows you to thoroughly review the audio file and to retrieve plenty of specific information and characteristics, the purpose of half of which we can only guess. Among others, there are beat detection, BPM, rhythm onset detection, rhythm transform, danceability, dynamic complexity, audio segmentation, key, scale, predominant melody and pitch, chords, spectral descriptors (spectral peaks, complexity, contrast, dissonance), time-domain descriptors (duration, loudness and a bunch of others), statistical descriptors (from mean to kurtosis and skewness). Actually, it’s exhaustive information about an audio file.
How to make use of it? I suppose all this information can be used by complex audio editors like Sony Sound Forge or Adobe Audition. A full-scale audio editor of such class on a mobile device is unlikely to be in high demand. It’s much more customary to edit an audio sitting in front of a PC screen. The developers, by the way, suggest using the library in a bunch with Python. And in case you are developing your own audio editor, spectral analysis, for example, will prove itself useful when performing noise suppression operation.
If to speak about the usage of this audio processing library for Android development, you will also have to use JNI and manually implement C++ code into the project.
Superpowered Audio SDK.
- superpowered.com
- Superpowered SDK is free for developing apps distributed in app stores. In other cases, it is necessary to contact Superpowered team for details. Superpowered HLS streaming technology is not a part of the SDK and is not free.
It’s a collection of C++ libraries for processing audio on the fly.
The SDK is a cross-platform (iOS, Android and OSX) and is promoted by developers as the fastest tool for audio processing. Moreover, it is said to have reduced CPU load which prolongs battery life and some other pleasant features.
The developer is offered to apply different audio effects like reverberation, echo, compressor, limiter, flanger, gate, mixer. To sum up, the effects so familiar to people who are keen on playing the guitar and have tried audio editing. There are also tools for analyzing the source of the audio which can also be partially used for voice processing. The SDK pack includes documentation and application samples.
As for creating a project for Android, according to the developers, there is no full integration with an Android project yet. You will have to apply some magic when working with the Gradle project build system. However, this process is explained in the documentation.
SpectrumWorx SDK.
I would also like to recall a tool called SpectrumWorx SDK.
There are demo-recordings with various audio effects open to public inspection. You can check out how everything will sound right away.
Trial versions of the SDKs are available for developers. In order to get one, you need to fill in a form and send a request. Unfortunately, I haven’t received any reply to my request.
Finally.
Above, I mentioned the main tools for realtime audio processing that I have come across while searching for a solution. The list, obviously, can be updated and extended. I described only those I got acquainted with during my research. I sincerely hope this information will come in handy to you, my dear readers.
Thank you for your attention to this article.
Источник
