音。機械的振動からALSASoCレイヤーまで

SberDevicesでは、音楽を聴いたり、映画を見たりすることができるデバイスを製造しています。ご想像のとおり、音がなければ、これはまったく問題になりません。学校の物理学からLinuxのALSAサブシステムまで、デバイスのサウンドに何が起こるかを見てみましょう。



私たちが聞く音は何ですか？完全に単純化するために、これらは私たちの耳に届く空気粒子の振動です。もちろん、彼らの脳は心地よい音楽や窓際を通り過ぎるモーターサイクリストの音に変換されますが、とりあえず振動にとどまりましょう。



19世紀に、人々はあなたが音の振動を記録してそれを再現することを試みることができることに気づきました。



まず、最初の録音デバイスの1つがどのように機能したかを見てみましょう。





フォノグラフとその発明者トーマスエジソン

写真提供



ここではすべてが簡単です。彼らはシリンダーを取り、それをホイルで包んだ。それから彼らは最後に膜で（それを大きくするために）先細りの何かを取りました。小さな針が膜に取り付けられています。針はホイルに寄りかかった。それから特別に訓練された人がシリンダーをひねって共鳴器に何かを言いました。膜によって駆動される針が、箔にくぼみを作りました。シリンダーを均等にねじるだけで十分な場合、膜の振動振幅のシリンダーへの「巻き」時間への依存性が明らかになります。







信号を再生するには、最初からシリンダーをもう一度回す必要がありました。針が溝に落ち、記録された振動を膜に伝達し、それを共振器に伝達します。だから私たちは録音を聞きます。愛好家による興味深い投稿をYouTubeで簡単に見つけることができます。

電気への移行

それでは、もっと現代的ですが、それほど複雑ではないものを見てみましょう。たとえば、リールマイク。空気の振動によりコイル内の磁石の位置が変化し、電磁誘導のおかげで、出力で磁石（したがって膜）の振動の振幅の時間依存性が得られます。今だけ、この依存性は、フォイルのくぼみではなく、マイクの出力の電圧の時間依存性によって表されます。







このような変動の表現をコンピュータのメモリに保存するには、それらを離散化する必要があります。これは、特別なハードウェアであるアナログ-デジタルコンバーター（ADC）によって行われます。 ADCは、入力の電圧値（ADC整数演算の分解能まで）を1秒間に何度も記憶し、メモリに書き込むことができます。このような1秒あたりのサンプル数は、サンプルレートと呼ばれます。一般的な値は8000Hz〜96000Hzです。



ADCは別の一連の記事に値するため、ADCの詳細については説明しません。主なことに移りましょう。Linuxドライバーやあらゆる種類のデバイスが動作するすべてのサウンドは、振幅と時間の依存関係の形で正確に表されます。この記録形式はPCM（パルスコード変調）と呼ばれます。持続時間が1 / sample_rateのタイムスライスごとに、音の振幅の値が示されます。 .wavファイルが作成されるのはPCMからです。



音楽付きの.wavファイルのPCM視覚化の例。横軸は時間、縦軸は信号振幅です。







ボードにはスピーカー用のステレオ出力があるため、ステレオサウンドを1つの.wavファイル（左右のチャンネル）に保存する方法を学ぶ必要があります。ここではすべてが単純です-サンプルは次のように交互になります：







データを保存するこの方法は、インターリーブと呼ばれます。他の方法もありますが、ここでは検討しません。



次に、デバイス間のデータ転送を整理するために必要な電気信号を把握しましょう。そして、それほど多くは必要ありません：

1. ビットクロック（BCLK）は、ハードウェアが次のビットをいつ送信するかを決定するためのクロック信号（またはクロック）です。
2. フレームクロック（FCLKまたはLRCLKとも呼ばれます）は、別のチャネルの送信を開始する必要があるときに機器が理解するタイミング信号です。
3. データはデータそのものです。

たとえば、次の特性を持つファイルがあります。

• サンプル幅= 16ビット;
• サンプリングレート= 48000 Hz;
• チャネル= 2。

次に、次の周波数値を設定する必要があります。

• FCLK = 48000 Hz;
• BCLK = 48000 * 16 * 2Hz。

さらに多くのチャネルを送信するために、TDMプロトコルが使用されます。これはI2Sとは異なり、FCLKのデューティサイクルを50％にする必要がなくなり、立ち上がりエッジは異なるチャネルに属するサンプルのパケットの開始のみを設定します。

一般的なスキーム

手元にあったのは、スピーカーを接続できるamlogics400ボードでした。アップストリームのLinuxカーネルがインストールされています。この例に取り組みます。



私たちのボードは、TAS5707PHPR DACが接続されているSoC（amlogic A113x）で構成されています。そして、一般的なスキームは次のようになります



。SoCでできること：

• SoCには、BCLK、LRCLK、DATAの3つのピンがあります。
• SoCの特別なレジスタを介してCLKピンを構成し、正しい周波数を持つようにすることができます。
• このSoCに次のように言うこともできます。「これがメモリ内のアドレスです。PCMデータが含まれています。このデータをDATA行を介して少しずつ送信します。」このメモリ領域はhwbufと呼ばれます。

サウンドを再生するために、LinuxドライバーはSoCにBCLKおよびLRCLKラインに設定する周波数を指示します。さらに、Linuxドライバーはhwbufがどこにあるかを教えてくれます。次に、DAC（TAS5707）はDATAラインを介してデータを受信し、それを2つのアナログ電気信号に変換します。これらの信号は、1対のワイヤを介して送信されます{アナログ+; アナログ-}を2つのスピーカーに。

Linuxへの移行

Linuxでこの回路がどのように見えるかに進む準備ができています。まず、Linuxでサウンドを操作するための「ライブラリ」があります。これはカーネルとユーザースペースの間に分散しています。それはALSAと呼ばれ、その名前を検討します。 ALSAの本質は、ユーザースペースとカーネルがサウンドデバイスを操作するためのインターフェイスで「合意」することです。



カスタムALSAライブラリは、ioctlインターフェイスを使用してカーネルと対話します。 / dev / snd /ディレクトリに作成されたpcmC {x} D {y} {c、p}デバイスが使用されます。これらのデバイスは、SoCベンダーが作成する必要のあるドライバーによって作成されます。たとえば、amlogics400のこのフォルダの内容は次のとおりです。

# ls /dev/snd/
controlC0    pcmC0D0p   pcmC0D0   pcmC0D1c   pcmC0D1p   pcmC0D2c

pcmC {x} D {y} {c、p}の名前で：

X-サウンドカード番号（いくつかある場合があります）。

Yは、カード上のインターフェイスの番号です（たとえば、pcmC0D0pはtdmインターフェイスを介してスピーカーで再生し、pcmC0D1c-は別のハードウェアインターフェイスを介してマイクからのサウンドを録音します）。

p-サウンドを再生するためのデバイス（再生）を示します。

c-音声を録音するためのデバイス（キャプチャ）を示します。



この場合、pcmC0D0pデバイスは再生I2Sインターフェイスに正確に対応します。D1はspdif、D2はpdmマイクですが、それらについては説明しません。

デバイスツリー

サウンドカードの説明は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";
};

ここでは、/ dev / sndに表示される3つのデバイス（tdmif_c、spdif、pdm）が表示されます。



音が伝わる装置はdai-link-6と呼ばれます。 TDMドライバーの制御下で動作します。疑問が生じます。I2S、そして突然TDMを介してサウンドを送信する方法について話していました。これは簡単に説明できます。上記で書いたように、I2Sは同じTDMですが、LRCLKのデューティサイクルとチャネル数の要件が明確になっています。2つあるはずです。次に、TDMドライバーはdai-format = "i2s"フィールドを読み取ります。彼はI2Sモードで作業する必要があることを理解します。



次に、speaker_amp1構造を使用して、どのDAC（Linux内では「コーデック」と呼ばれます）がボードにインストールされているかが示されます。どのI2Cラインに接続されているかがすぐに示されることに注意してください（I2Sと混同しないでください！）TAS5707DACが接続されています。アンプがオンになり、ドライバーから調整されるのはこの線に沿っています。



tdmif_c構造は、どのSoCピンがI2Sインターフェースとして機能するかを記述します。

ALSASoCレイヤー

内部でオーディオをサポートするSoCの場合、LinuxにはALSASoCレイヤーがあります。これにより、コーデックを記述でき（これは、DACがALSA用語で呼ばれるものであることを忘れないでください）、これらのコーデックの接続方法を指定できます。



Linuxカーネル用語のコーデックは、DAI（デジタルオーディオインターフェイス）と呼ばれます。SoC内にあるTDM / I2Sインターフェイス自体はDAIとも呼ばれ、それを使用する作業も同様の方法で実行されます。



ドライバは、structsnd_soc_daiを使用してコーデックを記述します。コーデックの説明で最も興味深い部分は、TDM送信パラメータを設定するための操作です。それらはここにあります：struct snd_soc_dai-> struct snd_soc_dai_driver-> structsnd_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（）です。

再生しようとしているPCMファイルのパラメーターに従ってすべてのSoCハードウェアを構成するために必要です。後で上記のグループの関数を呼び出してTDMクロックをインストールするのは彼女です。

...
int (*trigger)(struct snd_pcm_substream *, int,
    struct snd_soc_dai *);
...

そして、この関数は、コーデックを構成した後の最後のステップを実行します-コーデックをアクティブモードにします。



アナログサウンドをスピーカーに出力するDACは、まったく同じ構造で記述されています。この場合のsnd_soc_dai_opsは、正しい形式でデータを受信するようにDACを構成します。DACのこの設定は、通常、I2Cインターフェイスを介して行われます。



構造内のデバイスツリーで指定されているすべてのコーデック、

dai-link-6 {
    ...
    codec-1 {
        sound-dai = <&speaker_amp1>;
    };
};

-そしてそれらの多くが存在する可能性があり、1つのリストに追加され、/ 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 */
};

チェーン内のいずれかのコーデックが特定のパラメーターをサポートしていない場合、すべてがエラーで終了します。



amlogic s400に対応するTDMドライバーの実装は、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を介してサウンドを再生するように指示します）。



何が起こっていますか？

これが短いブロック図で、その後に説明が続きます。

1. [userspace] .wavヘッダーを解析して、再生されているファイルのPCMパラメーター（サンプルレート、ビット幅、チャネル）を見つけます。すべてのパラメーターをstructsnd_pcm_hw_paramsに追加します。
2. [ユーザースペース]デバイス/ dev / snd / pcmC0D0pを開きます。
3. [userspace] ioctl(…, SNDRV_PCM_IOCTL_HW_PARAMS ,…), PCM- .
4. [kernel] PCM-, . :
   
   
   • ;
   • .
5. , /dev/snd/pcmC0D0p ( ), .
6. [userspace] , PCM-.
7. [userspace] ioctl(…, SNDRV_PCM_IOCTL_WRITEI_FRAMES, …). I WRITEI , PCM- interleaved-.
8. [kernelspace] , /dev/snd/pcmC0D0p , .
9. [kernelspace] copy_from_user（）を使用して、ユーザーbufをhwbuf（一般スキームを参照）にコピーします。
10. [ユーザースペース] goto6。

ioctlのカーネル部分の実装は、SNDRV_PCM_IOCTL_ *という単語を検索することで表示できます。

結論

これで、Linuxカーネルのどこにサウンドが入るのかがわかりました。次の記事では、Androidアプリケーションからサウンドがどのように再生されるかを分析しますが、これにはまだ長い道のりがあります。