Linuxで音が出ない原因は、いくつかの層に分かれています。上から順に、アプリやデスクトップの設定、サウンドサーバー(PipeWireまたはPulseAudio)、ALSA、カーネルのドライバとファームウェアです。ALSAはカーネルに含まれる音声の基盤です。サウンドサーバーは、複数のアプリの音を混ぜてデバイスへ送るソフトウェアです。この記事では、手間が少なく原因として多いものから順に確認します。各段階の結果によって、次に見る場所が変わります。マイクが認識されない場合も同じ手順で確認できます。マイクに関わる箇所はその都度書き添えます。

ミュートと出力先・入力先の選択を確認する

最初に、ミュートと出力先を疑います。原因として最も多く、確認もすぐに終わります。キーボードのミュートキーは、押したつもりがなくても有効になっていることがあります。デスクトップのサウンド設定を開き、出力と入力の音量がゼロになっていないか、ミュートになっていないかを見ます。

次に出力先を確認します。HDMIでモニターをつないでいたり、Bluetoothヘッドホンを使ったことがあったりすると、出力先が別のデバイスに切り替わっていることがあります。ノートPCでは、内蔵スピーカーとヘッドホン端子が別々に表示される場合もあります。マイクも同じで、内蔵マイク、ヘッドセット、Webカメラのマイクなど、複数の入力先から正しいものが選ばれているかを確認します。

アプリ側の設定も見ます。ブラウザやビデオ会議アプリは、OSの既定とは別にデバイスを選べます。1つのアプリだけ音が出ないなら、そのアプリの設定が原因である可能性が高いと判断できます。どのアプリでも音が出ないなら、次の段階に進みます。

サウンドサーバーの状態を確認する(PipeWire/PulseAudio)

どちらのサウンドサーバーが動いているかを調べる

執筆時点では、多くの主要ディストリビューションがPipeWireを標準にしています。古い環境や一部の構成では、PulseAudioが使われています。次のコマンドで確認できます。

pactl info | grep 'Server Name'

出力に「PulseAudio (on PipeWire ...)」とあればPipeWireが動いています。「pulseaudio」とだけあればPulseAudioです。コマンドが接続エラーになる場合は、サウンドサーバーが起動していない可能性があります。この場合は、後述の再起動の手順に進みます。

PipeWireではwpctlで既定デバイスを確認する

PipeWire環境では、セッションマネージャーのWirePlumberに付属するwpctlを使います。

wpctl status

出力の「Audio」の欄に、Sinks(出力)とSources(入力)が並びます。行頭に「*」が付いているものが既定のデバイスです。意図したデバイスに「*」が付いていない場合は、行頭の番号(ID)を指定して切り替えます。

wpctl set-default 52
wpctl get-volume @DEFAULT_AUDIO_SINK@
wpctl set-mute @DEFAULT_AUDIO_SINK@ 0
wpctl set-volume @DEFAULT_AUDIO_SINK@ 0.8

52は例です。実際のIDは環境ごとに異なります。get-volumeの結果に「[MUTED]」と出たらミュート中です。マイクの場合は、SINKをSOURCEに置き換えた@DEFAULT_AUDIO_SOURCE@で同じ操作ができます。

pactlで確認する

PulseAudio環境や、pipewire-pulseが入っているPipeWire環境では、pactlも使えます。

pactl list short sinks
pactl list short sources
pactl set-default-sink デバイス名
pactl set-sink-mute @DEFAULT_SINK@ 0
pactl set-source-mute @DEFAULT_SOURCE@ 0

Sinksに目的のデバイスがあるのに音が出ない場合は、ミュートと既定の設定を直します。Sinksに目的のデバイスが表示されない場合は、次の「プロファイル」を確認します。

サウンドサーバーを再起動する

サウンドサーバーが止まっている、または応答しない場合は、ユーザー単位のサービスを再起動します。sudoは付けません。

# PipeWireの場合
systemctl --user restart pipewire pipewire-pulse wireplumber
# PulseAudioの場合
systemctl --user restart pulseaudio

再起動で直った場合でも、再発するならログを確認します。journalctl --user -u wireplumber -b や journalctl --user -u pipewire -b でエラーを探せます。

プロファイルの設定でデバイスが消えている場合

サウンドカードには「プロファイル」という動作モードがあります。プロファイルがオフになっていたり、HDMI出力専用のものになっていたりすると、スピーカーやマイクが一覧に出ません。pactl list cards を実行すると、「Profiles」に選べるプロファイルが、「Active Profile」に現在のプロファイルが表示されます。切り替えは、デスクトップのサウンド設定か、pavucontrolの「構成」タブで行えます。コマンドでは pactl set-card-profile を使います。

Bluetoothヘッドセットのマイクが使えない場合も、プロファイルが原因であることが多いです。音質を優先するA2DPプロファイルは、マイクに対応していません。マイクを使うには、HSP/HFP系のプロファイルに切り替えます。切り替えると、再生の音質が下がるのは仕様です。

ALSAレベルでデバイスが認識されているか確認する

サウンドサーバーにデバイスが見えない場合は、その下の層のALSAを調べます。次のコマンドはalsa-utilsパッケージに含まれます。

aplay -l
arecord -l

aplay -lは再生デバイスを、arecord -lは録音デバイスを一覧表示します。「no soundcards found」と出る場合や、目的のデバイスが一覧にない場合は、カーネルがデバイスを認識していません。この場合は、後述のドライバとファームウェアの節に進みます。

デバイスが一覧にあるなら、ALSAのミキサーを確認します。

alsamixer

F6キーでサウンドカードを選びます。各項目の下に「MM」と出ているものはミュート中です。Mキーで解除すると「00」になります。F4キーで録音側の表示に切り替わります。マイクの「Capture」が無効なら、スペースキーで有効にします。ノートPCでは「Auto-Mute Mode」が有効になっているために、ヘッドホン端子の誤検出で内蔵スピーカーが無音になる例もあります。

ALSAが正しく動くかは、speaker-test -c 2 -t wav で試せます。マイクは arecord -f cd -d 5 test.wav で5秒録音し、aplay test.wav で再生して確認します。ALSAでは音が出るのにデスクトップでは出ない場合は、原因がサウンドサーバーかその設定にあると絞り込めます。

ユーザーの権限とアプリの許可を確認する

現在の多くのディストリビューションでは、ログイン中のユーザーにサウンドデバイスへのアクセス権が自動で与えられます。この仕組みはsystemd-logindが管理しています。そのため、audioグループへの追加は通常は不要です。追加すると、別のユーザーのセッションと競合する原因になることもあります。ls -l /dev/snd/ でデバイスファイルを確認できます。getfacl /dev/snd/controlC0 を実行し、自分のユーザー名が表示されれば権限は付与されています。

sudoやrootで起動したアプリは、ユーザーのサウンドサーバーにつながらず、音が出ないことがあります。Flatpakで入れたアプリでマイクが使えない場合は、そのアプリにマイクの権限があるかを確認します。デスクトップ環境のプライバシー設定でも、マイクの使用を制限できます。

カーネルのドライバとファームウェアを確認する

aplay -lにデバイスが出ない場合は、ドライバが読み込まれているかを確認します。

lspci -nnk | grep -A3 -i audio
lsusb
sudo dmesg | grep -iE 'snd|sof|firmware'

lspciの出力に「Kernel driver in use」の行がない場合は、ドライバが読み込まれていません。USBマイクやUSBオーディオの場合は、lsusbに表示されるかを先に確認します。表示されない場合は、ケーブル、ポート、機器の故障を疑います。

比較的新しいIntel搭載のノートPCでは、内蔵のスピーカーやマイクがSOF(Sound Open Firmware)という仕組みで動いています。ファームウェアのファイルがないと、dmesgにファームウェアを読み込めないというエラーが出て、デバイスが認識されません。対処として、ファームウェアのパッケージを導入します。パッケージ名はディストリビューションによって異なります。Debian/Ubuntu系ではfirmware-sof-signed、Fedoraではalsa-sof-firmware、Arch Linuxではsof-firmwareです。導入後は再起動します。新しい機種では、カーネルが古いことが原因の場合もあります。この場合は、カーネルを更新すると改善することがあります。

ここまでで直らないときの次の手

次に取るべき行動は、どの段階で異常が見つかったかで決まります。ALSAでは音が出るのにデスクトップで出ない場合は、サウンドサーバーの設定を初期化します。まずWirePlumberの状態ファイル(~/.local/state/wireplumber/)を別名に退避してから、サービスを再起動します。ALSAでもデバイスが見えない場合は、ハードウェアの問題かソフトウェアの問題かを切り分けます。最新のディストリビューションのライブUSBで起動して試すのが確実です。ライブUSBで音が出るなら、ソフトウェア側の問題と判断できます。原因はカーネルやファームウェアの版、または設定です。ライブUSBでも音が出ず、別のOSでも出ない場合は、ハードウェアの故障を疑います。

フォーラムやバグ報告で質問するときは、次の情報を添えると回答を得やすくなります。ディストリビューションとカーネルのバージョン(uname -r)、aplay -lとwpctl statusの出力、dmesgのエラー行です。ALSAプロジェクトが配布しているalsa-info.shスクリプトを使うと、これらの情報をまとめて収集できます。