Debianでサスペンド復帰後に「Dummy Output」になったときの復旧メモ

別記事でも書いているVAIOですが、もともとWindowsで使っていたVAIOにDebianを追加して、WindowsとDebianのデュアルブートにしました。
（あと、ディスクも1TBのSSDに変更しました）
最近はDebian側でも普段の作業をしています。

ただ、使っていると時々音が出なくなります。
サスペンドから戻したあとに「あれ、音が出ないな」となることが多いです。

音声出力を開くと「Dummy Output」が選ばれていました。
スピーカーの項目もあるのに、音が出ない。。。

PipeWireまわりを再起動したら音が出るようになったので、次に忘れないようにメモしておきます。

今回の環境

対象のPCで確認した環境は以下の通りです。

サスペンドから復帰すると「Dummy Output」になる

音量を上げてみても変わらず。画面右上のメニューから出力先を確認すると、こんな状態でした。
「Speaker – Tiger Lake-LP Smart Sound T...」の下に「Dummy Output」があり、そちらにチェックが付いています。

PipeWireとWirePlumberを再起動する

とりあえず、ターミナルを開いてPipeWireとWirePlumberを再起動。

systemctl --user restart pipewire pipewire-pulse wireplumber

これで音が出るようになりました。
これまでは都度PCごと再起動してたので、コマンドでいけるなら今後は一旦これでしのぐか。。。

ログインしているユーザーのサービスなので、--userを付けます。sudoは不要です。
再起動中は音声が途切れるので、Webミーティングなどが始まる前に確認して、必要なら実行するようにしています。

実行後も音が出なければ、音声出力でスピーカーが選ばれているかも確認してみてください。

実機のログから原因を調べてみる（結果、何も分からんかった）

音は出たものの、何が起きていたのか気になったので、あとからログも見てみました。

まずは音声サービスのログを確認

journalctl --user --since '2026-10-24' -u pipewire -u pipewire-pulse -u wireplumber --no-pager

10月24日と25日に、デバイスがビジーで開けないというエラーが何度か出ていました。
以下は10月25日15時13分49秒のログです。（ホスト名などは省略）

pipewire: spa.alsa: '_ucm0004.hw:sofhdadsp': playback open failed: デバイスもしくはリソースがビジー状態です
wireplumber: s-monitors: Failed to create alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink: Object activation aborted: PipeWire proxy destroyed

スピーカーだけでなく、HDMI出力でも同じエラーが出ています。
音声デバイスを開けず、出力先を作るところで失敗していたようです。ただ、この時刻に画面でも「Dummy Output」が出ていたかは記憶が曖昧。。。

ログイン画面と通常ユーザーのサービスが同時に起動していた？

何かがデバイスを使っていたのかと思い、同じ時間帯のシステムログも確認します。

sudo journalctl -b -2 --since '2026-10-25 15:13:40' --until '2026-10-25 15:14:00' --no-pager

このときの-b -2は2回前の起動を指定しています。
起動番号は変わるので、調べるときはjournalctl --list-bootsで確認してください。

すると、普段使っているユーザー（UID 1000）と、UID 110の両方でPipeWireとWirePlumberが起動していました。
getent passwd 110で調べると、UID 110はログイン画面用のDebian-gdmでした。

自分のユーザーは/var/lib/systemd/linger/にも登録されていて、ログイン前からユーザーサービスが動く状態でした。
ログイン画面側と、音声デバイスの取り合いになったのか？とも思ったのですが、その瞬間に誰が使っていたかまでは分からず。

両方でサービスが起動していたのは確かですが、これだけでGDMやlingerが原因とは決められなさそうです。

サスペンドとの時間関係も確認

sudo journalctl --since '2026-10-24' _TRANSPORT=kernel --no-pager | grep -Ei 'PM: suspend|PM: resume|suspend entry|suspend exit|sof.*(error|fail|timeout|panic)'

サスペンドの記録は、10月25日0時1分43秒に入って、14時14分15秒に復帰。
ところが、先ほどの15時13分49秒のエラーは、その後にPCを起動し直したときのものでした。

サスペンド復帰後に起きる印象だったのですが、起動直後にも同じように出力の作成に失敗しています。
復帰の処理だけを疑えばいい、というわけでもなさそうです。

ドライバーと現在の出力先を確認

lspci -k -s 00:1f.3
cat /proc/asound/cards
wpctl status

ドライバーはsof-audio-pci-intel-tgl、ALSAのカード名はsof-hda-dspでした。
起動ログにはSOFファームウェアの読み込みと、Realtek ALC269VBの初期化も残っています。

調べた時点では復旧済みで、wpctl statusにもSpeakerが既定の出力として出ていました。HDMI出力やマイクも見えています。
ほかにCould not open any dma-buf providerやleaked proxyも出ていましたが、前者はカメラの初期化付近、後者はサービス停止時のログ。今回の音声の件に関係するのかは分かりませんでした。

次に発生したら、再起動前に確認したいこと

今回は直ってから時間が経って、ふと思い立って調べたので、肝心のビジー状態のときに誰がデバイスを使っていたのか分かりませんでした。
次に出たら、再起動する前にこのあたりを見ておこうと思います。

date --iso-8601=seconds
systemctl --user status pipewire pipewire-pulse wireplumber --no-pager
wpctl status
cat /proc/asound/cards
ps -eo user,pid,comm | grep -E 'pipewire|wireplumber|pulseaudio'
sudo fuser -v /dev/snd/*
journalctl --user -b -u pipewire -u pipewire-pulse -u wireplumber --no-pager -n 200

fuserで音声デバイスを使っているプロセスを見て、wpctl statusの結果と一緒に残しておきたいところです。
今回調べたときは、自分のユーザーのPipeWireとWirePlumberだけで、GDMの音声プロセスは見当たりませんでした。

原因を決めきれなかったので、設定は変えずにいったんここまで。サスペンドさせての再現確認も、まだやっていません。

原因は宿題。とりあえず音は出た

ひとまず、自分の環境ではPipeWireまわりの再起動で音が戻りました。

デバイスがビジーになっていた記録は見つかったものの、誰と取り合っていたのかは分からず。。。

毎回このコマンドを打つのも面倒なので、次に出たときはログを取ってから直すことにします。（忘れずに取れるといいですが。。。）