1. Происхождение ASoC:

ASoC — ALSA System on Chip — это программная система, построенная на стандартном уровне драйверов ALSA для лучшей поддержки аудиокодеков во встроенных процессорах и мобильных устройствах. До появления ASoc ядро ​​уже имело частичную поддержку звука в SoC, но были некоторые ограничения:

• Базовая связь между драйвером кодека и процессором SoC слишком тесная. Эта неудовлетворительная ситуация приведет к дублированию кода. Например, в то время в Linux существовали только коды драйверов для четырех платформ.
• Не существует стандартного способа уведомления пользователей о событиях Аудио.,Например, обнаружение подключения и отключения наушников и микрофонов.,Эти события очень распространены на мобильных устройствах.,И часто для перенастройки AudioRoadjin требуется машинно-специфичный код.
• При воспроизведении или записи драйвер будет держать весь кодек включенным. Для ПК это не проблема, но для мобильных устройств это означает большую трату энергии. В то же время не поддерживается достижение целей энергосбережения путем изменения частоты передискретизации и тока смещения.

ASoC был предложен для решения вышеуказанных проблем и был интегрирован в дерево кода ядра: sound/soc. ASoC не может существовать отдельно. Он основан только на стандартном драйвере ALSA. Для работы его необходимо объединить со стандартной структурой драйверов ALSA.

2. Аппаратная архитектура:

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

• Машина относится к определенной машине,Это может быть определенное устройство,Определенная плата разработки,Или определенный смартфон,Из этого видно, что Машина практически не многоразовая.,Аппаратная реализация на каждой машине может быть разной.,ЦП другой,Кодек другой,Устройства ввода и вывода Аудио также различаются.,Машина обеспечивает носитель для ЦП, кодека, а также устройств ввода и вывода.
• Платформа обычно относится к определенной платформе SoC.,Например, pxaxxx, s3ccxxxx, omapxxx и т. д.,К аудио обычно относятся часы, DMA, I2S, PCM и т. д. в SoC.,Пока указан SoC,Тогда можно подумать, что у него будет соответствующая Платформа.,Это относится только к SoC,Ничего общего с машиной,Таким образом, мы можем абстрагировать платформу,Чтобы в ту же SoC не нужно было вносить никаких изменений,Его можно использовать в разных машинах. на самом деле,Лучше думать о платформе как об определенном SoC.
• Кодек буквально означает кодек. Кодек включает в себя интерфейс I2S, D/A, A/D, микшер, PA (усилитель мощности) и обычно содержит несколько входов (микрофонный, линейный вход, I2S, PCM) и несколько выходов (наушники, динамики). , наушники, линейный выход), Кодек, как и Платформа, является компонентом многократного использования. Один и тот же кодек может использоваться на разных машинах. Встроенный кодек обычно управляет внутренними регистрами через I2C.

3. Архитектура программного обеспечения:

На уровне программного обеспечения ASoC также разделяет аудиосистему встроенных устройств на три части: машина, платформа и кодек.

Драйвер кодека Важным принципом проектирования ASoC является то, что драйвер кодека не зависит от платформы. Он содержит некоторые элементы управления звуком (элементы управления), аудиоинтерфейсы, определения DAMP (динамическое управление питанием звука) и определенные функции ввода-вывода кодека. Чтобы обеспечить независимость оборудования, любой код, специфичный для платформы и машины, необходимо переместить в драйверы платформы и машины. Все драйверы кодеков должны обеспечивать следующие функции:

• Информация о конфигурации кодека DAI и PCM;
• Метод управления вводом-выводом кодека (I2C, SPI и т. д.);
• Микшер и другие элементы управления аудио;
• Рабочий интерфейс кодека ALSA Audio;

При необходимости также могут быть предусмотрены следующие функции:

• информация описания DAPM;
• Обработчик событий DAPM
• Цифровое управление отключением звука ЦАП
• Драйвер платформы Содержит настройку и управление интерфейсом AudioDMAи Аудио платформы SoC (I2S, PCM, AC97 и т.д.) Не может содержать никакого кода, связанного с платой или машиной.
• Водитель машины Водитель машина отвечает за обработку некоторых событий управления, специфичных для машины (например, при воспроизведении Аудио необходимо сначала включить усилитель отдельной Платформы и Драйвера); Кодека не работает, это должен сделать Водитель машины. Их объединение может завершить работу по обработке звука на всем устройстве.

4. Структура данных:

Весь ASoC состоит из ряда структур данных. Чтобы понять механизм работы ASoC, вы должны понять взаимосвязь и роль этой серии структур данных. Следующая диаграмма отношений показывает взаимосвязь между важными структурами данных в ASoC:

Рисунок 4.1 Статическая связь между различными структурами в Kernel-2.6.35-ASoC

ASoC реализует звуковую карту как платформенное устройство, а затем использует поле dev в структуре Platform_device: dev.drvdata, которое фактически указывает на структуру snd_soc_device. Можно считать, что snd_soc_device является основой всей структуры данных ASoC. Начиная с него, выводится ряд структур данных для выражения различных характеристик и функций звука. Структура snd_soc_device ведет к двум структурам snd_soc_card и soc_codec_device, а затем snd_soc_card ведет к структурам snd_soc_platform, snd_soc_dai_link и snd_soc_codec. Как упоминалось выше, ASoC разделен на три части: Машина, Платформа и Кодек. Из этих структур данных snd_codec_device и snd_soc_card представляют драйвер машины, snd_soc_platform представляет драйвер платформы, snd_soc_codec и soc_codec_device представляют драйвер кодека, а snd_soc_dai_link отвечает за подключение. Платформа и кодек.

5. Улучшения ASoC в ядре версии 3.0:

Версия ядра, на которую первоначально ссылались при написании этой статьи, была 2.6.35, но друг CSDN предположил, что ASoC внесла серьезные изменения в версию ядра 3.0. Поэтому я намеренно скачал код 3.0 и обнаружил, что изменения действительно есть. Вот статическая диаграмма отношений структуры данных:

Рисунок 5.1 Структура данных ASoC в ядре 3.0

На рисунке выше мы видим, что структура данных в версии 3.0 более разумна и понятна. Структура snd_soc_device была отменена и заменена непосредственно на snd_soc_card, а роль snd_soc_pcm_runtime была усилена. также были добавлены , используемые для четкого представления драйвера кодека и драйвера платформы.

Ссылка на статью: https://blog.csdn.net/DroidPhone/article/details/7165482.