Регистрация

[Звук, Научно-популярное, Системное программирование] Звук. От механических колебаний до ALSA SoC Layer

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
22-Сен-2020 12:31
Цитировать


Мы в SberDevices делаем устройства, на которых можно послушать музыку, посмотреть кино и ещё много всего. Как вы понимаете, без звука это всё не представляет интереса. Давайте посмотрим, что происходит со звуком в устройстве, начиная со школьной физики и заканчивая ALSA-подсистемой в Linux.
Что же такое звук, который мы слышим? Если совсем упрощать, то это колебания частиц воздуха, которые доходят до нашей барабанной перепонки. Мозг их, разумеется, потом переводит в приятную музыку или в звук проезжающего за окном мотоциклиста, но давайте пока остановимся на колебаниях.
Люди ещё в 19 веке поняли, что можно попытаться записать звуковые колебания, а потом их воспроизвести.
Для начала посмотрим, как работало одно из первых звукозаписывающих устройств.

Фонограф и его изобретатель Томас Эдисон
Источник фото
Тут всё просто. Брали какой-нибудь цилиндр, обматывали фольгой. Потом брали что-нибудь конусообразное (чтобы было погромче) с мембраной на конце. К мембране присоединена маленькая иголка. Иголку прислоняли к фольге. Потом специально обученный человек крутил цилиндр и что-нибудь говорил в резонатор. Иголка, приводимая в движение мембраной, делала в фольге углубления. Если достаточно равномерно крутить цилиндр, то получится «намотанная» на цилиндр зависимость амплитуды колебаний мембраны от времени.

Чтобы проиграть сигнал, надо было просто прокрутить цилиндр ещё раз с начала — иголка будет попадать в углубления и передавать записанные колебания в мембрану, а та — в резонатор. Вот мы и слышим запись. Можно легко найти интересные записи энтузиастов на ютубе.
Переход к электричеству
Теперь рассмотрим что-нибудь более современное, но не очень сложное. Например, катушечный микрофон. Колебания воздуха теперь изменяют положение магнита внутри катушки и благодаря электромагнитной индукции мы получаем на выходе зависимость амплитуды колебаний магнита (а значит, и мембраны) от времени. Только теперь эта зависимость выражается не углублениями на фольге, а зависимостью электрического напряжения на выходе микрофона от времени.

Чтобы можно было хранить такое представление колебаний в памяти компьютера, их надо дискретизировать. Этим занимается специальная железка — аналогово-цифровой преобразователь (АЦП). АЦП умеет много раз за одну секунду запоминать значение напряжения (с точностью до разрешения целочисленной арифметики АЦП) на входе и записывать его в память. Количество таких отсчётов за секунду называется sample rate. Типичные значения 8000 Hz – 96000 Hz.
Не будем вдаваться в подробности работы АЦП, потому что это заслуживает отдельной серии статей. Перейдём к главному — весь звук, с которым работают Linux-драйверы и всякие устройства, представляется именно в виде зависимости амплитуды от времени. Такой формат записи называется PCM (Pulse-code modulation). Для каждого кванта времени длительностью 1/sample_rate указано значение амплитуды звука. Именно из PCM состоят .wav-файлы.
Пример визуализации PCM для .wav-файла с музыкой, где по горизонтальной оси отложено время, а по вертикальной — амплитуда сигнала:

Так как на нашей плате стереовыход под динамики, надо научиться хранить в одном .wav-файле стереозвук: левый и правый канал. Тут всё просто — сэмплы будут чередоваться вот так:

Такой способ хранения данных называется interleaved. Бывают и другие способы, но сейчас их рассматривать не будем.
Теперь разберёмся, какие электрические сигналы нам нужны, чтобы можно было организовать передачу данных между устройствами. А нужно не много:
  • Bit Clock(BCLK) — тактирующий сигнал (или клок), по которому аппаратура определяет, когда надо отправить следующий бит.
  • Frame Clock (FCLK или его ещё называют LRCLK) — тактирующий сигнал, по которому аппаратура понимает, когда надо начать передавать другой канал.
  • Data — сами данные.


Например, у нас есть файл со следующими характеристиками:
  • sample width = 16 bits;
  • sampling rate = 48000 Hz;
  • channels = 2.

Тогда нам надо выставить следующие значения частот:
  • FCLK = 48000 Hz;
  • BCLK = 48000 * 16 * 2 Hz.

Чтобы передавать ещё больше каналов, используется протокол TDM, который отличается от I2S тем, что FCLK теперь не обязан иметь скважность 50%, и восходящий фронт лишь задаёт начало пакета сэмплов, принадлежащих разным каналам.
Общая схема
Под рукой как раз оказалась плата amlogic s400, к которой можно подключить динамик. На неё установлено ядро Linux из upstream. На этом примере и будем работать.
Наша плата состоит из SoC (amlogic A113x), к которому подключен ЦАП TAS5707PHPR. И общая схема выглядит следующим образом:

Что умеет SoC:
  • SoC имеет 3 пина: BCLK, LRCLK, DATA;
  • можно сконфигурировать CLK-пины через специальные регистры SoC, чтобы на них были правильные частоты;
  • ещё этому SoC можно сказать: «Вот тебе адрес в памяти. Там лежат PCM-данные. Передавай эти данные бит за битом через DATA-линию». Такую область памяти будем называть hwbuf.

Чтобы воспроизвести звук, Linux-драйвер говорит SoC, какие нужно выставить частоты на линиях BCLK и LRCLK. К тому же Linux-драйвер подсказывает, где находится hwbuf. После этого ЦАП (TAS5707) получает данные по DATA-линии и преобразует их в два аналоговых электрических сигнала. Эти сигналы потом передаются по паре проводов {analog+; analog-} в два динамика.
Переходим к Linux
Мы готовы перейти к тому, как эта схема выглядит в Linux. Во-первых, для работы со звуком в Linux есть «библиотека», которая размазана между ядром и userspace. Называется она ALSA, и рассматривать мы будем именное её. Суть ALSA в том, чтобы userspace и ядро «договорились» об интерфейсе работы со звуковыми устройствами.
Пользовательская ALSA-библиотека взаимодействует с ядерной частью с помощью интерфейса ioctl. При этом используются созданные в директории /dev/snd/ устройства pcmC{x}D{y}{c,p}. Эти устройства создаёт драйвер, который должен быть написан вендором SoC. Вот, например, содержимое этой папки на amlogic s400:
# ls /dev/snd/
controlC0    pcmC0D0p   pcmC0D0с   pcmC0D1c   pcmC0D1p   pcmC0D2c

В названии pcmC{x}D{y}{c,p}:
X — номер звуковой карты (их может быть несколько);
Y — номер интерфейса на карте (например, pcmC0D0p может отвечать за воспроизведение в динамики по tdm интерфейсу, а pcmC0D1c — за запись звука с микрофонов уже по другому аппаратному интерфейсу);
p — говорит, что устройство для воспроизведения звука (playback);
c — говорит, что устройство для записи звука (capture).
В нашем случае устройство pcmC0D0p как раз соответствует playback I2S-интерфейсу. D1 — это spdif, а D2 — pdm-микрофоны, но о них мы говорить не будем.
Device tree
Описание звуковой карты начинается с device_tree [arch/arm64/boot/dts/amlogic/meson-axg-s400.dts]:
…
sound {
    compatible = "amlogic,axg-sound-card";
    model = "AXG-S400";
    audio-aux-devs = <&tdmin_a>, <&tdmin_b>,  <&tdmin_c>,
             <&tdmin_lb>, <&tdmout_c>;
           …
    dai-link-6 {
        sound-dai = <&tdmif_c>;
        dai-format = "i2s";
        dai-tdm-slot-tx-mask-2 = <1 1>;
        dai-tdm-slot-rx-mask-1 = <1 1>;
        mclk-fs = <256>;
        codec-1 {
            sound-dai = <&speaker_amp1>;
        };
    };
           …
    dai-link-7 {
        sound-dai = <&spdifout>;
        codec {
            sound-dai = <&spdif_dit>;
        };
    };
    dai-link-8 {
        sound-dai = <&spdifin>;
        codec {
            sound-dai = <&spdif_dir>;
        };
    };
    dai-link-9 {
        sound-dai = <&pdm>;
        codec {
            sound-dai = <&dmics>;
        };
    };
};
…
&i2c1 {
    speaker_amp1: audio-codec@1b {
        compatible = "ti,tas5707";
        reg = <0x1b>;
        reset-gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_LOW>;
        #sound-dai-cells = <0>;
               …
    };
};
&tdmif_c {
    pinctrl-0 = <&tdmc_sclk_pins>, <&tdmc_fs_pins>,
            <&tdmc_din1_pins>, <&tdmc_dout2_pins>,
            <&mclk_c_pins>;
    pinctrl-names = "default";
    status = "okay";
};

Тут мы видим те 3 устройства, которые потом окажутся в /dev/snd: tdmif_c, spdif, pdm.
Устройство, по которому пойдёт звук, называется dai-link-6. Работать оно будет под управлением TDM-драйвера. Возникает вопрос: вроде мы говорили про то, как передавать звук по I2S, а тут, вдруг, TDM. Это легко объяснить: как я уже писал выше, I2S — это всё тот же TDM, но с чёткими требованиями по скважности LRCLK и количеству каналов — их должно быть два. TDM-драйвер потом прочитает поле dai-format = «i2s»; и поймёт, что ему надо работать именно в I2S-режиме.
Далее указано, какой ЦАП (внутри Linux они входят в понятие «кодек») установлен на плате с помощью структуры speaker_amp1. Заметим, что тут же указано, к какой I2C-линии (не путать с I2S!) подключен наш ЦАП TAS5707. Именно по этой линии будет потом производиться включение и настройка усилителя из драйвера.
Структура tdmif_c описывает, какие пины SoC будут выполнять роли I2S-интерфейса.
ALSA SoC Layer
Для SoC, внутри которых есть поддержка аудио, в Linux есть ALSA SoC layer. Он позволяет описывать кодеки (напомню, что именно так называется любой ЦАП в терминах ALSA), позволяет указывать, как эти кодеки соединены.
Кодеки в терминах Linux kernel называются DAI (Digital Audio Interface). Сам TDM/I2S интерфейс, который есть в SoC, тоже называется DAI, и работа с ним проходит схожим образом.
Драйвер описывает кодек с помощью struct snd_soc_dai. Самая интересная часть в описании кодека — операции по выставлению параметров передачи TDM. Находятся они тут: struct snd_soc_dai -> struct snd_soc_dai_driver -> struct snd_soc_dai_ops. Рассмотрим самые важные для понимания поля (sound/soc/soc-dai.h):
struct snd_soc_dai_ops {
    /*
     * DAI clocking configuration.
     * Called by soc_card drivers, normally in their hw_params.
     */
    int (*set_sysclk)(struct snd_soc_dai *dai,
        int clk_id, unsigned int freq, int dir);
    int (*set_pll)(struct snd_soc_dai *dai, int pll_id, int source,
        unsigned int freq_in, unsigned int freq_out);
    int (*set_clkdiv)(struct snd_soc_dai *dai, int div_id, int div);
    int (*set_bclk_ratio)(struct snd_soc_dai *dai, unsigned int ratio);
    ...
Те самые функции, с помощью которых выставляются TDM-клоки. Эти функции обычно имплементированы вендором SoC.
...
int (*hw_params)(struct snd_pcm_substream *,
    struct snd_pcm_hw_params *, struct snd_soc_dai *);
...
Самая интересная функция — hw_params().
Она нужна для того, чтобы настроить всё оборудование SoC согласно параметрам PCM-файла, который мы пытаемся проиграть. Именно она в дальнейшем вызовет функции из группы выше, чтобы установить TDM-клоки.
...
int (*trigger)(struct snd_pcm_substream *, int,
    struct snd_soc_dai *);
...
А эта функция делает самый последний шаг после настройки кодека — переводит кодек в активный режим.
ЦАП, который будет выдавать аналоговый звук на динамик, описывается ровно такой же структурой. snd_soc_dai_ops в этом случае будут настраивать ЦАП на прием данных в правильном формате. Такая настройка ЦАП как правило осуществляется через I2C-интерфейс.
Все кодеки, которые указаны в device tree в структуре,
dai-link-6 {
    ...
    codec-1 {
        sound-dai = <&speaker_amp1>;
    };
};

— а их может быть много, добавляются в один список и прикрепляются к /dev/snd/pcm* устройству. Это нужно для того, чтобы при воспроизведении звука ядро могло обойти все необходимые драйверы кодеков и настроить/включить их.
Каждый кодек должен сказать какие PCM-параметры он поддерживает. Это он делает с помощью структуры:
struct snd_soc_pcm_stream {
    const char *stream_name;
    u64 formats;            /* SNDRV_PCM_FMTBIT_* */
    unsigned int rates;     /* SNDRV_PCM_RATE_* */
    unsigned int rate_min;      /* min rate */
    unsigned int rate_max;      /* max rate */
    unsigned int channels_min;  /* min channels */
    unsigned int channels_max;  /* max channels */
    unsigned int sig_bits;      /* number of bits of content */
};

Если какой-нибудь из кодеков в цепочке не поддерживает конкретные параметры, всё закончится ошибкой.
Соответствующую реализацию TDM-драйвера для amlogic s400 можно посмотреть в sound/soc/meson/axg-tdm-interface.c. А реализацию драйвера кодека TAS5707 — в sound/soc/codecs/tas571x.c
Пользовательская часть
Теперь посмотрим что происходит, когда пользователь хочет проиграть звук. Удобный для изучения пример реализации пользовательской ALSA — это tinyalsa. Исходный код, относящийся ко всему нижесказанному, можно посмотреть там.
В комплект входит утилита tinyplay. Чтобы проиграть звук надо запустить:
bash$ tinyplay ./music.wav -D 0 -d 0
(-D и -d параметры говорят, что звук надо проигрывать через /dev/snd/pcmC0D0p).
Что происходит?
Вот краткая блок-схема, а потом будут пояснения:
  • [userspace] Парсим .wav header, чтобы узнать PCM-параметры (sample rate, bit width, channels) воспроизводимого файла. Складываем все параметры в struct snd_pcm_hw_params.
  • [userspace] Открываем устройство /dev/snd/pcmC0D0p.
  • [userspace] Обращаемся к ядру с помощью ioctl(…, SNDRV_PCM_IOCTL_HW_PARAMS ,…), чтобы узнать поддерживаются такие PCM-параметры или нет.
  • [kernel] Проверяем PCM-параметры, которые пытается использовать пользователь. Тут есть два типа проверок:
    • на общую корректность и согласованность параметров;
    • поддерживает ли каждый задействованный кодек такие параметры.
  • настраиваем под них все кодеки, которые прикреплены к /dev/snd/pcmC0D0p интерфейсу (но пока не включаем), возвращаем успех.
  • [userspace] выделяем временный буфер, куда будем класть PCM-данные.
  • [userspace] отдаем заполненный временный буфер ядру с помощью ioctl(…, SNDRV_PCM_IOCTL_WRITEI_FRAMES, …). Буква I в конце слова WRITEI указывает, что PCM-данные хранятся в interleaved-формате.
  • [kernelspace] включаем кодеки, которые прикреплены к /dev/snd/pcmC0D0p интерфейсу, если они еще не включены.
  • [kernelspace] копируем пользовательский буфер buf в hwbuf (см. пункт «Общая схема») с помощью copy_from_user().
  • [userspace] goto 6.

Реализацию ядерной части ioctl можно посмотреть, поискав по слову SNDRV_PCM_IOCTL_*
Заключение
Теперь у нас есть представление о том, куда попадает звук в Linux ядре. В следующих статьях будет разбор того, как звук проигрывается из Android-приложений, а для этого ему надо пройти ещё немалый путь.
 ===========
 Источник:
habr.com
===========
Похожие новости: Теги для поиска: #_zvuk (Звук), #_nauchnopopuljarnoe (Научно-популярное), #_sistemnoe_programmirovanie (Системное программирование), #_linux_kernel, #_alsa, #_audio (аудио), #_blog_kompanii_sberdevices (
Блог компании SberDevices
), #_blog_kompanii_sberbank (
Блог компании Сбербанк
), #_zvuk (
Звук
), #_nauchnopopuljarnoe (
Научно-популярное
), #_sistemnoe_programmirovanie (
Системное программирование
)
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 10:46
Часовой пояс: UTC + 5