Raspberry Pi Zero W で無線 LAN を使ったリモート・マイクを実現する (1)

河本孝之（KAWAMOTO Takayuki）

Contact: takayuki.kawamoto@markupdancing.net

ORCID iD icon ORCID, Google Scholar, PhilPapers.

First appeared: 2021-03-02 14:31:03,
Modified: [BLANK],
Last modified: 2022-01-06 13:05:36.

残念ながら本稿は未完です。この後の記事を作成する予定はありません。悪しからずご了承ください。理由の一つは、headless インストールの記事でも少し書きましたが、実際にはマイクの性能が悪くて音の入力が小さく、聞こえる大きさまでスピーカーのボリュームを上げるとノイズが酷くて常用には耐えられなかったからです。また、pulseAudio のプロセスを常に起動したままにしておくような運用が安定しているとは思えなかったので、Raspberry Pi Zero W を使ったリモート・スピーカーのプランはあきらめて、USB コンデンサー・マイクと 7m の 3.5mm オーディオ・ケーブルを購入して、マイクから拾った音を直にスピーカーで鳴らすプランに変更しています（これでも、マイクが安物なので音が小さい）。

新しく買ったマイクとケーブル

はじめに

先に公開した「Raspberry Pi Zero W の headless セットアップ」では、Raspberry Pi OS Lite の headless セットアップまでを説明しました。今回は、その記事の冒頭で書いた目的に見合うような、リモート・マイクのシステムを実現する手順について説明します。本稿は、実装の条件なり選択したソフトウェアや設定が更に具体的な内容となって実践的な記事であると言える反面、色々な点で汎用性に欠ける偏りがあると思うので、本稿の内容だけがリモート・マイクを実現する唯一の方法でもなければ、正しい方法であるとも限らないと強調しておきます。

冒頭に戻る

要件を整理する

まず、何をしたいのか正確に要件を決めないといけません。要件があやふやだと、何か分からないことがあるたびに曖昧な条件で調べることとなり、邪魔どころか逆効果となるような情報を目にしたり、無意味なのか逆効果なのか結果が分からないまま試してみるという愚行を繰り返すことになります。もちろん、多くの場合には、そういう情報を公表している人たちが悪いわけではありません。しかし、中には過剰な SEO で役に立たない記事をばら撒いている事例があるため、なるべくそういうクズを掴まないように、検索条件を厳しくするためにも要件は正確に定めるべきでしょう。

Requirement

上の画像が今回の目的を表す模式図です。左の送信側 Raspberry Pi では、USB マイクで玄関のチャイム音を拾ってから、音声データをストリーミングでリアルタイムに送信する必要があります。このため、動画での監視システムとか、録音での監視システムとか、あるいは送信側で他のリソースから取得した番組音声やローカルに保存している音楽ファイルをストリーミングで配信するような仕組みを解説しているページは、要件が違っています。右の受信側 Raspberry Pi では、無線 LAN を経由して受け取った音声データを USB-A から 3.5mm のイヤホン・ジャックのコネクタへ変換するアダプタを通して、ごく普通のスピーカーを鳴らすために使います。こちらも、音声データを受ける側で何をしたいのかによっては、DTM とか録音とか、特に今回の目的では関係のないシステムを組み込むような手順を説明しているページも多いため、場合によっては導入するソフトウェアやそれの設定内容がオーバー・スペックになっていたり、今回の目的には不適切な内容となっている可能性があります。そうしたページを参考にするとしても、自分の目的に照らして適しているかどうかを判断できる材料がなければ、迂闊に読むことはできません。

ということで、送信側は (1) USB マイクでチャイムの音声を取り込むしくみと、(2) 取り込んだ音声を無線 LAN でストリーミングするしくみ、受信側は (3) ストリーミングされた音声データを受け取るしくみと、(4) 受け取った音声データを出力するしくみが必要です。これらのうち、(1) と (4) は接続するデバイスのドライバという話にもなりますが、何にせよ Raspberry Pi とのインターフェイスとしては USB で接続することを前提にした情報を探せばよいでしょう。そして (2) と (3) では組み込むソフトウェアが異なる（ストリーミング配信と受信の両方に対応するソフトウェアがあると決めつけるわけにはいかない）という前提で、それから当たり前のことだとは思いますが、ひとまず (2) を先に検討してから (3) を検討します。（通信プロトコルさえ対応していれば、(3) を後から検討しても問題はありません。対応するソフトウェアが存在しないプロトコルで音声データを配信するようなソフトウェアを書く人は、PoC: proof of concept を目的としていない限りいない筈だからです。）

なお、これ以降は送信側 Raspberry Pi、つまりマイク側という意味で、僕の自宅に設置した実物の Raspberry Pi に設定してあるホスト名の “rpzw01” を使います。それから受信側 Raspberry Pi、つまりスピーカー側も “rpzw02” と呼びます。もちろん、これらのホスト名は /etc/hostname や /etc/hosts に設定している文字列であり、ターミナル・エミュレータなどで接続するときは “rpzw01.local” のように特別な suffix を付けてアクセスします（また、複数台の Raspberry Pi を同一のネットワークで運用するときは、ホスト名をそれぞれ独自に設定しない限り、“raspberrypi.local” というディフォールトのホスト名では異なる Raspberry Pi へアクセスできないわけです。なお、Raspberry Pi Zero W の IP アドレスを固定して IP アドレスでアクセスする方法もあります）。それから２台の Raspberry Pi については、OS は前回の記事でご紹介した Raspberry Pi OS Lite（2021年2月, 2021-01-11-raspios-buster-armhf-lite.img）でセットアップしていて、上記のとおり、それぞれに “rpzw01,” “rpzw02” というホスト名を設定したりロケールやタイムゾーンを変更しています^*。以下の解説は、ほぼその状態から始めた手順です。（あと、.vimrc や .bashrc を編集するといった軽微なカスタマイズはしていますが、今回の事案には殆ど影響のない話です。）

^*上記の二つのファイル（/etc/hostname, /etc/hosts）に書かれている、“raspberrypi” というディフォールトのホスト名を変更してから reboot もしくは sudo reboot すれば反映されます。なお、プロンプトの “#” と “%”（または “$”）との意味の違いはお分かりだという前提で書いていますので、これ以降はいちいち root でコマンドを打つ場合と一般ユーザでコマンドを打つ場合とを併記するような手間はかけません。プロンプトの種類に応じて、ご自身の環境で実行する方法に読み替えて下さい。

冒頭に戻る

送信側 Raspberry Pi（rpzw01）のマイクをセットアップする

上記で説明したように、rpzw01 では USB マイクで音声を受け取るという処理から始まります。実際には USB マイクなら Raspberry Pi Zero W の端子に接続するだけで認識されたので、特に何か複雑な準備をしたわけではありません。

rpzw01 set up (1)

用意した USB マイクは Mini USB Microphone (PRODUCT ID: 3367) という小型で安いものです（本来は Limor Fried という女性経営者が率いるニューヨークの ADAFRUIT 社が製造しているマイクのことです。但し、僕が手に入れた製品は中国製で、ADAFRUIT 社が中国の工場や企業にライセンスを供与している事実はないので・・・まぁ後はお察しください）。このマイクは USB の Type-A という標準的なインターフェイスのため、Raspberry Pi Zero W の USB microB のインターフェイスへ接続するには、別に販売されているアダプタ（上記の写真で中央の器材。あるいは同等のケーブルでも可）が必要です。マイクはそれなりに実勢価格が変動するので1,000円弱と言っておきますが、上記のようなアダプタはせいぜい300円以内でしょう。取り付ける向きに注意して、上の写真で右端のようになります。

rpzw01 set up (2)

実際に Raspberry Pi Zero W（rpzw01）へマイクを接続すると、上の写真のようになります。ここで注意しておきたいのは、一つ上の写真でも加工した後から撮影したので既に元の形状ではないのですが、このマイクはそのままだと右の USB ケーブル（電源用ケーブル）が邪魔で接続できないのです。無理にやれば差し込めますが、マイクの半円形の黒いケースが隣の USB ケーブルの端子を押してしまい、これでは基板の端子（を圧着している半田）に無理な力を加え続けたりコネクタの接触に問題を起こす可能性があります。そこで、マイクのケースは端を削っても動作に影響はないだろうと判断して、糸鋸で 2mm ほど端を切り落としてあります。

上記の写真で分かるように、奇妙なことに両端を切り落としていますが、これは僕が最初に切り落とす側を間違えたからであって、正しい側だけを切り落とせば十分です。なお、両端を切り落としてしまったためか、ケースが開いてしまったので、後からボンドでケースを再び接着しました。

ということで、rpzw01 の物理的な準備はこれで終わりです。USB マイクで音を拾うだけなのですから、これ以外に何も必要ありません。そこで、次に Teraterm Pro のようなターミナル・エミュレータで rpzw01 へアクセスして、今度はソフトウェアでのセットアップに入ります。

rpzw01 set up (3)

まず何よりも最初に、USB マイクが Raspberry Pi そして Raspberry Pi OS に認識されているのかどうかを確認することから始めなくてはなりません。そこで、lsusb コマンドで確かめます。

pi@rpzw01:~ $ lsusb
Bus 001 Device 002: ID 8086:0808 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

“Intel Corp.” と表示されているものが USB マイクです。次の行は Raspberry Pi の基板に搭載されている USB のホスト・コントローラから接続している USB 2.0 規格のルート HUB であり、Raspberry Pi Zero W には USB のインターフェイスが二つあるため、内部的には root として HUB が表示されます。USB のバスは “Bus 001” と表示されていて、それに接続しているデバイスの ID が、ルート HUB は “001” で（USB の場合はホスト・コントローラが HBA: host bus adaptor として電源も供給するため、これが電源の USB 端子でもある）、それ以外に接続している場合は他の番号というわけなので、この “Device 002” が USB のマイクだと分かります。次に、以下のような確認をしました。

pi@rpzw01:~ $ cat /proc/asound/modules
1 snd_usb_audio

これは、多くの Linux システムに標準で入っている ALSA (the Advanced Linux Sound Architecture)、すなわちサウンド制御用に開発されたカーネル・コンポーネントの設定内容の一つです。/proc/asound には ALSA が利用するハードウェアの情報が格納されていて、カーネルやカーネルのモジュールが参照するようになっています。/proc/asound/modules は読み取り専用のファイルであり、サウンド・カードのドライバとして ALSA に登録された一覧を示します（カーネルに読み込まれているというだけの ALSA 用のモジュールを示しているわけではないので、混同しないようにしましょう）。ともあれ、上記で 1 snd_usb_audio と一覧に上がっていることで、USB マイクのドライバが ALSA に登録されていることが分かります。

更に、次のような確認方法でデバイスの番号も分かります。

root@rpzw01:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

上記の結果から、「カード ID:１、デバイス ID: ０」であることが判明しました。これは他のコマンドでも USB マイクを指定するときに使えます。ということで、 ALSA から認識されていることが分かったので、試しにマイクを使って音を取り込む試験をしましょう。例えば、以下のようにコマンドを入力すると録音が始まります。Ctrl + c で停止します。

pi@rpzw01:~ $ arecord -V mono -D hw:1 -f S16_LE -r 48000 /tmp/test.wav

ちなみに、コマンドのオプションとパラメータとを繋げて “-r48000” などとタイプする人も多いのですが、可読性、つまりコマンドを眺めている人間がトークン処理させられる負荷を考えると、筋のよい習慣とは思えません。“-r 48000” のようにパラメータを分割してタイプしたり表記することをお勧めします。

それから、オンラインの記事やページには ALSA の附属ツールである arecord と aplay に同じオプションが使えるからといって、雑に同じものとして扱う人もいるようですが、たとえば上記のような目的でコマンドを叩いた結果を紹介する際に、マイクのデバイス情報を調べるのに aplay -l などと打ち込んだログを掲載するのは、無神経にもほどがあります。（実際には、マイクの場合にデバイス情報が出力される保証はありません。）

rpzw01 set up (4)

arecord は ALSA の録音ツールです（なお、リンクしてあるページは少し古いので、man ページを見たほうがいいでしょう）。オプションを順番に説明すると、まず -V は、録音中に表示されるテキスト・ベースの VU メータ（上の画像で “###+” などと表示されるもの）を２チャネルで表示するかどうかです。僕が使う USB マイクはモノラルなので、このオプションに “mono” と設定しても “stereo” と設定しても、表示されるメーターは１チャネルです。また、-c というオプションでチャネル数を指定できたりするわけですが、モノラルのマイクで２とか３と指定しても無意味ですから、モノラルのマイクではオプションとして指定する必要がないので、ここでは -c オプションは省略してあります。

次に、-D は録音するデバイスを指定しています。PCM 名を指定するということになりますが、これはヴァーチャルなサウンド・カードにも対応するための仕様であり、具体的なカードの ID が分かっている場合は、素直に ID を使って指定したほうが確実です。これは、/proc/asound/cards に登録されている ID（僕の事例では “1”）を使って、“hw:1” と指定します。カードにデバイスが幾つか接続される場合には、更にデバイスの ID を付けて “hw:1,0” などと指定します。この “hw:1,0” というのは、実際には /dev/snd にある PCM デバイス・ファイルを見つけるための指示内容となっています。実際、/dev/snd の中を見ると、“PCMC1D0c” というキャラクタ・デバイスがあります。これを通して、デバイス・ドライバとのデータのやりとりができるようになります。なお、デバイスの指定方法は /usr/share/alsa/alsa.conf に詳しく書かれていて、このフォーマットを参考にすると、僕の運用する環境では、“hw:1” は “hw:1,0” と書いても “pcm.plughw:1,0” と書いても同じであることが分かります。“plughw” と記述すると、ALSA がデバイスへ直にアクセスするのではなく、プラグイン・レイヤーで（本来はデバイスが対応していないサンプリング・レートでも扱えるように）自動でデータを変換してくれるようになります。したがって、後の -r といったオプションの指定を “-r 96000” などと間違えていても、可能な限りで対応します。

次の -f は対応可能なフォーマット、そして -r はサンプリング・レート（「サンプル・レート」とか「サンプリング周波数」などと呼ぶこともあります）を指定します。これは man ページでもお分かりのとおり色々なフォーマットやサンプリング・レートを指定できます。しかし、USB マイクが対応するフォーマットやサンプリング・レートは特定の値に限られるため、これは USB マイクの情報から指定するしかありません。USB マイクの情報は、/proc/asound の中にカードの ID を使って /proc/asound/card1 のようなディレクトリがあると、その中に “stream0” といったファイルがあります（/proc/asound/card1/pcm0c/sub0/hw_params を見たら良いと書いている人もいますが、それはデバイスが稼働中に限ります）。この中身を見ると、以下のとおり出力されます。

root@rpzw01:/proc/asound/card1# cat stream0
C-Media Electronics Inc. USB PnP Sound Device at usb-20980000.usb-1, full speed : USB Audio
Capture:
  Status: Stop
  Interface 1
    Altset 1
    Format: S16_LE
    Channels: 1
    Endpoint: 2 IN (ADAPTIVE)
    Rates: 48000, 44100
    Bits: 16

この情報から、フォーマットは S16_LE（Signed 16 bit Little Endian）で、サンプリング・レートが 48,000 Hz か 44,100 Hz であることが分かります。（２種類のサンプリング・レートに対応しているのは、それぞれ映像系の業界、音響系の業界でサウンドを処理する場合のデファクト・スタンダートなサンプリング・レートだからです。一般論として言えば、サンプリング・レートの値は大きいほうが良いと言えますが、人の耳で聴いて分かる範囲の違いを超えた値を設定しても現実的ではありません。また、サンプリング・レートの異なるデータを組み合わせると、時間経過に伴って音がズレる恐れがあります。なので、数値なら何でも許容されるからといって、一般的でない値を指定するべきではありません。もっとも、実際にはヘンテコな値を使うと ALSA に「レートが不正確です」と警告されて補正されてしまうわけですが。）

Ctrl + c で録音を停止すると /tmp/test.wav という WAV 形式の音声ファイルが生成されるので、これを WinSCP のような scp over ssh でアクセスできるツールで Raspberry Pi からダウンロードして再生すれば、録音した音が聴ける筈です。

rpzw01 set up (5)

多くの環境ではディフォールトで ALSA を使うと録音レベルが低い（録音した音が小さい）ようなので、これは ALSA の設定を変更した方がよいでしょう。但し、多くのウェブ・ページでは alsamixer とタイプするだけで起動すると解説していますが、少なくとも Raspberry Pi OS Lite の環境だと “cannot open mixer: No such file or directory” というエラーが出てしまいます。この場合、僕の環境では alsamixer のオプションである -c（カード ID）を指定して、alsamixer -c 1 とすれば alsamixer が起動します。

rpzw01 set up (6)

理由はよく分かりませんが、幾つか選べるメニューで F2（システム情報）や F4（キャプチャ）を選ぶと alsamixer が落ちてしまうか強制的に抜けてしまうため、必要なことだけやって済ませましょう。まず、F5 で録音レベルを調整できる全てのデバイスを表示させます。分かりにくい UI ですが、項目の文字が赤くなっている方が選択されている項目を表していますから、矢印キーで “Mic” の方を選びます。

rpzw01 set up (7)

すると、矢印キーの上下で録音レベルを調整できますから、↑ で録音レベルを最大にしましょう。僕が使っている USB マイクだと、録音レベルを最大にしても依然として録音した音がさほど大きくありません。ひとまず聴ける音の大きさにしたいので、最大に設定して構いません。その状態で設定が完了するため、Esc で alsamixer から抜けます。

rpzw01 set up (8)

メニューには “Exit” としか書いていませんが、実際には設定した内容が終了時に保存されています。設定した内容は、/var/lib/alsa/asound.state というファイルに保存されるので、それを開くと “Mic Capture Volume” の値が “16” つまり最大に設定されている筈です。

コマンドラインで設定する場合は、まず ALSA でマイクの録音レベルがどう設定されているかを確認しないといけません。それには、amixer というコマンドを使います。

root@rpzw01:~# amixer -D hw:1
Simple mixer control 'Mic',0
  Capabilities: cvolume cvolume-joined cswitch cswitch-joined
  Capture channels: Mono
  Limits: Capture 0 - 16
  Mono: Capture 16 [100%] [23.81dB] [on]
Simple mixer control 'Auto Gain Control',0
  Capabilities: pswitch pswitch-joined
  Playback channels: Mono
  Mono: Playback [on]

arecord のオプションにも言えるように、ややこしいのですが、-D はカード ID を指定します（“D” ですがデバイス ID ではありません。嫌な人は amixer -c 1 で同じ結果が返ってきます）。すると、上記のとおり２種類の結果が返ってきます。後者の “Auto Gain Control” は、もちろんゲイン（入力音に対する内部増幅）の調節量ですから、入力する音の大きさ調節とは別のしくみです。ゲインを変えると音が割れてしまったりしますし、そもそも僕が使う USB マイクではゲインを自由に調節できないため、こちらは無視しても構いません。

録音レベルを変更（設定）する場合も、amixer を使って、以下のようにします。

root@rpzw01:~# amixer -c 1 set 'Mic' 5
Simple mixer control 'Mic',0
  Capabilities: cvolume cvolume-joined cswitch cswitch-joined 
  Capture channels: Mono
  Limits: Capture 0 - 16
  Mono: Capture 5 [31%] [7.44dB] [on]

-c は同じ意味ですが、set [CONTROL] [PARAMETER] で調整パラメータを指定します。[CONTROL] には設定したい対象（括弧で囲まれている名前）を指定して、[PARAMETER] には設定したい録音レベルを指定します。ボリューム値は、“Limits” で示される数値でもかまいませんし、“50%” のように百分率でもかまいません。ただ、これだけだと一時的に値を変更したにすぎません。実際、/var/lib/alsa/asound.state の（ファイルの場所は OS によって異なる場合があります）“Mic Capture Volume” に書き込まれている録音レベルは amixer で設定した値になっていないので、これを ALSA の設定として保存するには alsactl store というコマンドで設定を保存しないといけません（コマンドの詳しい使い方は man ページを参照すると良い筈です。alsa.opensrc.org は内容が少し古いので、このコマンドについて解説は掲載されていません）。

冒頭に戻る

受信側 Raspberry Pi（rpzw02）のスピーカー（イヤフォン）をセットアップする

わざわざ章立てして書いていますが、実はさほど書くことはありません。なぜなら、マイクに関するセットアップとスピーカー（イヤフォン）に関するセットアップは、手順としては殆ど同じだからです（もちろん、ハードウェアとしては詳細な違いがあります）。実際、ご存知の方にとっては些末なことと思われるかもしれませんが、ご存知ない方のために説明しておくと、マイクとスピーカーの物理的な仕組みはだいたい「同じ」と言っていいものです [Zyra]。何かの機会があって急に録音したいという時にマイクが手元にない場合は、イヤフォンをマイクの代わりに使う事例もあります（もちろん、音を出すときの信号調整機構と音を取り込むときの信号調節機構は違うので、いくら仕組みが同じだと言っても本物のマイクより音質は劣ります）。結局、空気の振動を信号に変換すること、つまりマイクがやってることと、信号から空気の振動に変換すること、つまりスピーカーがやってることは、物理的に殆ど同じ仕組みの逆動作でしかありません。ということで、マイクについて言えることの多くはスピーカーについても言えるため、Raspberry Pi Zero W で利用するならなおさら、USB で接続しているという点でも同じですから、扱いも似たような手順になります。

ただし、僕の環境では用意したものが次のような機材の一式となっていますので、ご紹介しておきます。自宅にある、ごく普通のスピーカーで音を出したいという要件がありますから、スピーカー（もしくは試験的に繋ぐイヤフォン）は 3.5mm ジャックで接続することが前提です。すると、Raspberry Pi Zero W の USB 端子に接続するインターフェイスとしては、もちろん Raspberry Pi 側では microB の USB 端子なので、相手は 3.5mm のプラグを挿し込む端子であることが望ましいでしょう。しかし、microB 端子と 3.5mm 端子を変換するアダプタというのは、商品として販売されてはいるのですが、２台目の Raspberry Pi Zero W を購入したときに microB 端子から Type-A 端子に変換するアダプタが付属してきたので（下の写真で左側）、汎用性を考えると Type-A 端子から 3.5mm 端子に変換するアダプタの方が重宝するのではないかと考えて（それならパソコンにも直に接続できます）、USB Type-A から 3.5mm 端子へ変換するアダプタを購入しました（下の写真で右側）。

rpzw02 set up (1)

後は、USB マイクをセットアップしたときの手順と同じように、lsusb などで認識されていることを確認したり、カード ID やデバイス ID を確認します。

root@rpzw02:~# lsusb
Bus 001 Device 002: ID 1b3f:2008 Generalplus Technology Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@rpzw02:~# cat /proc/asound/modules
  1 snd_usb_audio
root@rpzw02:~# arecord -l
**** ハードウェアデバイス CAPTURE のリスト ****
カード 1: Device [USB Audio Device], デバイス 0: USB Audio [USB Audio]
  サブデバイス: 1/1
  サブデバイス #0: subdevice #0

上記のあと、alsamixer で、今度は再生するときの音の大きさを設定したわけですが、今度はマイクとスピーカーの両方がデバイスとして現れました。なんにせよ、どれも 100% の値にセットしておきます。

rpzw02 set up (2)

以上で設定は終わりなので、ALSA で動作を試してみましょう。マイクのときは arecord を使いました。今回も、ローカルに再生するべき音声を録音しておく必要がありますから、以下のように何秒かの音を録音します。但し、今度はマイクではなくイヤフォンを 3.5mm ジャックに接続して、イヤフォンに向かって音を出します。rpzw01 で録音したときと同じく、Ctrl + c で停止します。

arecord -V mono -D hw:1 -f S16_LE -r 48000 /tmp/test.wav

そして、この /tmp/test.wav として録音した音声ファイルを、同じイヤフォンで今度は聞いてみるわけです。このとき aplay というコマンドを使いますが、オプションは arecord と同じなので、再生したいデバイスの ID と、再生したいファイルのパスを指定すれば ALSA が再生します。

root@rpzw02:~# aplay -D plughw:1,0 /tmp/test.wav
再生中 WAVE '/tmp/test.wav' : Signed 16 bit Little Endian, レート 48000 Hz, モノラル

録音しただけの秒数が経過したら、もちろん再生は終わります。上記のコマンドでちゃんと録音できているかどうか、イヤフォンなど接続している機器で聴いてみたら確認できると思います。

接続したイヤフォンやスピーカーの挙動だけを手っ取り早く確認する場合は、上記のような手順よりも speaker-test というコマンドを使うほうが速いでしょう。たとえば、これまでの作業でカード ID 等は分かっているのですから、次のようにコマンドを叩いてわざとノイズ音を出せます。なお、僕の環境ではデバイスを hw:1,0 と指定しても音は出なかったので、plughw:1,0 という仮想化したデバイスとしてアクセスするとノイズ音が出ました。（ID の指定値は、“1,0” でも “1” でもノイズ音は出ました。）

pi@rpzw02:~ $ speaker-test -D plughw:1 -t sine -f 1000

rpzw02 set up (3)

次の (2) では、当然のように扱ってきた ALSA についてツールや設定の解説をしておきます。ここまでの手順でもデバイスを認識しなかったり録音できなかったりするトラブルが生じる可能性はありますから、ALSA のツールを扱う際に使えるオプションだとか、ALSA がハードウェアを認識したりハードウェアにアクセスするときに参照する設定内容を知っておくと、対策の見当を付けられる可能性が出てきます。

冒頭に戻る

References

Mordechai Guri, Yosef Solewicz, Andrey Daidakulov, and Yuval Elovici

2016

“SPEAKE(a)R: Turn Speakers to Microphones for Fun and Profit,” https://arxiv.org/abs/1611.07350; retrieved on February 20th, 2021.

mickey

2015

「ざっくりとALSAとPulseAudioの関係」,『みつきんのメモ』, April 4th, 2015, https://mickey-happygolucky.hatenablog.com/entry/2015/04/04/105512; retrieved on February 21st, 2021.

2019

「ざっくりとALSAとPulseAudioの関係(の続きのようなもの)」,『みつきんのメモ』, August 30th, 2019, https://mickey-happygolucky.hatenablog.com/entry/2019/08/30/125038; retrieved on February 21st, 2021.

Lieven Moors

2009

Introduction to Linux & Audio (a series of twelve lectures.) https://lievenmoors.github.io/; retrieved on February 21st, 2021.

Masumi Mutsuda

2012

“Raspberry Pi into an audio spying device,” mutsuda, https://blog.mutsuda.com/raspberry-pi-into-an-audio-spying-device-7a56e7a9090e; retrieved on February 20th, 2021.

Jan Newmarch

2016

“Programming and Using Linux Sound - in depth,” Version 1.02, jan.newmarch.name, January 4th, 2016, https://jan.newmarch.name/LinuxSound/index.html; retrieved on February 24th, 2021.

2017

Linux Sound Programming. Apress Media: California, 2017.

Zyra

????

“All Speakers are Microphones,” Zyra's Website, http://www.zyra.global/www.zyra.org.uk/sp-mic.htm; retrieved on February 20th, 2021.

冒頭に戻る