Kein Ton über HDMI mehr nach Bildschirmsperre

[Kriss1]

Mich plagt schon seit einigen Monaten das Problem, dass nach einer Sperre des Bildschirms (Super-Taste + L) oder längerer Inaktivität das komplette Soundsystem bei mir reproduzierbar abstürzt, d.h. es kommt kein Ton mehr über HDMI.

Wie geschrieben ist der Fehler reproduzierbar und leider nur durch einen Neustart behebbar:
Bei gleicher Hardware hatte ich unter EndeavourOS und Ubuntu das gleiche Problem und daher gehofft, dass es eventuell mit Debian Bullseye gelöst sein könnte, was leider nicht zutrifft (da die genannten Betriebssysteme ja auch auf Debian basieren).

In den letzten Monaten wurden alle Einstellungen überprüft: Der Fehler scheint nicht im Bereich von Pulseaudio und im inzwischen aktivierten PipeWire zu liegen, sondern eher im Bereich ALSA.

Eine gute Anleitung zur Problemlösung habe ich in folgender Anleitung gefunden:
https://wiki.ubuntuusers.de/Sound_Problembehebung/
Diese gilt zwar primär für Ubuntu, dürfte jedoch für mein inzwischen installiertes Debian auch gültig sein:
Leider brachten die Hinweise dort keinen Erfolg in meinem Falle.

Zusammengefasst lässt sich sagen, dass im Falle eines Fehlers der folgende Befehl, welcher Pulseaudio und Pipewire umgeht, keinen Ton über HDMI liefert (nach einem Reboot aber sehr wohl):

Code: Alles auswählen

$ speaker-test -c2 -D plughw:0,3 --test=wav -w /usr/share/sounds/alsa/Front_Center.wav

Wie könnte ich vorgehen, um das Problem einzugrenzen? Ich stelle gerne Systeminfos oder Befehlsausgaben zur Verfügung. Danke.

[towo]

Hilft dir zwar nicht, aber

(da die genannten Betriebssysteme ja auch auf Debian basieren).

Du solltest vielleicht nochmal nachdenken!
EndevourOS basiert auf Arch, nix Debian.

Wie könnte ich vorgehen, um das Problem einzugrenzen? Ich stelle gerne Systeminfos oder Befehlsausgaben zur Verfügung. Danke.

Normaler Weise nennt man im ersten Post zumindest seine benutzte Hardware.
Und Ausgaben von

Code: Alles auswählen

dmesg

und

Code: Alles auswählen

journalctrl -b -p err

nach dem Auftreten des Problems, könnte Erhellung bringen.

[Kriss1]

Ja gerne:

Code: Alles auswählen

$ dmesg
dmesg: Lesen des Kernelpuffers ist fehlgeschlagen: Die Operation ist nicht erlaubt

$ journalctl -b -p err
Feb 17 22:39:54 FUTRO-S740 pipewire[770]: (alsa_output.pci-0000:00:0e.0.hdmi-stereo-37) XRun! count:37 time:8554951947 delay:4215393802 max:4215393802
Feb 17 22:49:35 FUTRO-S740 pipewire-pulse[769]: stream 0x55d959cfc970: error no node available
Feb 17 22:49:35 FUTRO-S740 pipewire-pulse[769]: stream 0x55d9594555d0: error no node available
Feb 17 22:58:46 FUTRO-S740 pipewire-pulse[769]: stream 0x55d95a60ebb0: error no node available

verwendete Hardware / Software:
Futro S740
Intel® Celeron(R) J4105 CPU @ 1.50GHz × 4
Mesa Intel® UHD Graphics 600 (GLK 2)
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC671 Analog [ALC671 Analog]
Debian GNU/Linux 11 (bullseye)

Im gerade reproduzierten Fehlerfall steht dann leider auch bei Pulseaudio-Lauststärkeregler unter "Ausgabegeräte" ein falsches nicht vorhandenes Gerät (Headphones) anstelle dem erwarteten HDMI.

[towo]

Ich würde mal versuchen, das System mit

Code: Alles auswählen

intel_iommmu=igfx_off

als Bootparamter zu booten und schauen, ob es das Problem beseitigt.
Alternativ kann man noch

Code: Alles auswählen

intel_iommu=off 

und

Code: Alles auswählen

intel_iommu=pt

versuchen, falls das Erste nicht ausreicht.

Ansonsten wäre noch interessant, welcher Kernel läuft und ob Du firmware-misc-nonfree installiert hast.

[Kriss1]

Zumindest das konnte ich herausfinden, ich hoffe, es hilft weiter:
Kernel:

Code: Alles auswählen

$ uname -r 
5.10.0-21-amd64

Code: Alles auswählen

$ dpkg --list 'firmware*'
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                  Version                    Architektur  Beschreibung
+++-=====================-==========================-============-=======================================================
un  firmware-amd-graphics <keine>                    <keine>      (keine Beschreibung vorhanden)
ii  firmware-ath9k-htc    1.4.0-106-gc583009+dfsg1-1 all          firmware for AR7010 and AR9271 USB wireless adapters
ii  firmware-linux-free   20200122-1                 all          Binary firmware for various drivers in the Linux kernel
un  firmware-misc-nonfree <keine>                    <keine>      (keine Beschreibung vorhanden)

Wie man Bootparameter für den Bootvorgang dem System mitgibt, weiß ich leider noch nicht, bin mir nicht sicher, ob ich das mit google so herausfinde. Hier steht ev. etwas: https://www.reddit.com/r/linuxhardware/ ... uigfx_off/
Bin mir nicht ganz sicher, ob das für mich verständlich / durchführbar ist.

[towo]

Grub, "e" drücken, zu der Zeile, die mit "linux" anfängt navigieren, ans Ende der Zeile springen und das genannte dort eintragen.
Wenn es hilft, kann man das dann auch fest in die Grub Konfig eintragen.

firmware-misc-nonfree solltest Du installieren!
Und ein aktuellerer Kernel dürfte auch nicht schaden, diesen kann man aus den Backports installieren.

[Kriss1]

Gut, in Bezug auf den neueren Backports-Kernel musste ich erst mal nach einer verständlichen Anleitung suchen:
https://www.renefuerst.eu/debian-11-ker ... backports/
Ich denke, nach dieser Anleitung in Verbindung mit dem Video (und dem dortigen Hinweis auf den Fehler bullseye anstelle buster) könnte ich es mal in einer ruhigen Stunde probieren.

Eine Anleitung für firmware-misc-nonfree meine ich unter folgendem Link inkl. Anweisung gefunden zu haben (amd Version, nicht arm):
https://debian.pkgs.org/11/debian-nonfr ... l.deb.html
Über die Synaptic-Paketverwaltung ist es zumindest nicht installierbar.

Und dann noch die Sache mit den Bootparametern und ein Backup zuvor. Das dauert aber bei mir noch eine gewisse Zeit.

[Kriss1]

In einem anderen Forum habe ich jetzt einen Antwort bekommen, die auf einen bekannten Fehler im snd-hda-intel Treiber und dem aktuellen Kernel hinweist:

https://bugzilla.kernel.org/show_bug.cgi?id=208511#c8

Folgendes ist zu machen:

Code: Alles auswählen

sudo nano /etc/modprobe.d/audio.conf

Dort die folgende Option eintragen:

Code: Alles auswählen

options snd_hda_intel power_save_controller=0

Was jetzt noch stört im gleichen Kontext, d.h. bei einer Reproduktion des damaligen Fehlerfalles:
- Nach einer Bildschirmsperre (Super+L) und Anmeldung kehrt das Audio zwar wieder zurück, jedoch nicht in der ursprünglichen Lautstärke, sondern viel zu laut
- die individuell konfigurierten Tastendrücke für "Lauter" und "Leiser" funktionieren durch diese Maßnahme nicht mehr, die Lautstärke kann nur noch auf üblichem Wege reguliert werden kann (Lautstärkesymbol rechts oben).
- ein Restart der beiden Pipewire Services ändert auch nichts an der Sache.
- ich hätte auch nichts dagegen, sofern bei einer Bildschirmsperre der Ton einfach weiterläuft (ohne Bild), wie ich es unter Ubuntu kenne. Aber das ist kein Muss.