[gelöst] kein Sound nach Suspend-to-RAM

[snowy]

Habe auf einem Laptop Debian Stretch am Laufen.
Auf dem System gibt es (neben root) zwei User, UserA mit Admin-Rechten und ein UserD als Desktop-User

UserA hat ganz normal Sound, Pulse-Audio zeigt die interne Soundkarte, alles klappt wie gewünscht.
UserD bekommt in keinem Programm irgendein Ton, Pulse-Audio zeigt eine Dummy-Soundcard ???

Wissentlich habe ich keinerlei Besonderheiten eingerichtet, einfache Standard-Installation.
UserD ist auch in einer Gruppe Audio (falls dies von Belang ist).

Wo kann man nachsehen, woran es klemmen könnte, daß UserD keine Soundcard findet?
Danke für alle Tipps und Hinweise

NACHTRAG: Annahme Zusammenhang mit unterschiedlichen user-Rechten ist falsch, siehe weiter unten

[smutbert]

Also eigentlich sollte sich pulseaudio mit systemd-logind insofern absprechen als immer nur die Pulseaudioinstanz des gerade aktiven Nutzers Zugriff auf die Audiohardware erhält. Dafür sollte dann auch die Mitgliedschaft in der Gruppe audio überflüssig sein, weil das über ACLs gelöst wird.
(Demzufolge könnte ich mir bei Szenario vorstellen, dass eine Mitgliedschaft bei audio von UserA uU problematisch sein kann, aber eher nicht von UserD)

Was sagt

Code: Alles auswählen

$ getfacl /dev/snd/controlC0

(während es mit dem UserD nicht klappt?)

UserA verwendet ebenfalls Pulseaudio, oder?
Tritt das Problem unabhängig davon auf ob UserA Gebrauch macht von der Möglichkeit Töne wiederzugeben?

Welche Meldungen fördert

Code: Alles auswählen

# journalctl -p7 _EXE=/usr/bin/pulseaudio

zutage?

edit:
Wenn ich es mir recht überlege, könnte das Pulseaudio von UserD wegen der audio-Mitgliedschaft unabhängig von systemd-logind versuchen auf die Audiohardware/Alsa zuzugreifen, noch bevor UserA sie (zwangs)freigegeben hat. Es ist zumindest einen Versuch wert die audio-Mitgliedschaft zu entfernen.

[snowy]

Hi @smutbert,

habe gerade festgestellt, daß mein aktuelles Problem nur nach einem Suspend-to-RAM auftritt und wir beide vor 6 Monaten schon mal an dem Thema auf dem identischen Rechner waren
viewtopic.php?f=25&t=169319

Der Rechner wird nicht so häufig benutzt und schon gar nicht mit Ton, deshalb ist erst jetzt wieder aufgefallen, daß der Workaround zwischenzeitlich nicht mehr funktioniert
Aufgerufen wird er aber immer noch

Code: Alles auswählen

#!/bin/bash

case "${1}" in
	post)
		/bin/echo 1 > "/sys/bus/pci/devices/0000:00:1b.0/remove"
		/bin/sleep 0.5
		/bin/echo 1 > /sys/bus/pci/rescan
		;;
esac

und die Device-Adresse hat sich auch nicht geändert. Aber scheinbar hat irgendein Update zwischenzeitlich den Workaround unwirksam gemacht
hast Du evtl. einen neuen Ansatz ?

[smutbert]

Das tritt also in Wirklichkeit benutzerunabhängig auf?

Im alten Thread war es ja anscheinend etwas hardware- bzw. kernel-/treibernahes, aber wenn es nun nur mit einem Benutzer auftritt bzw. der Fehler mit einem andere Benutzer nicht auftritt, dann liegt es kaum an Hardware oder Kernel/Treibern.

Ein Killen aller Pulseaudio-Prozesse bringt auch nix (das startet eh wieder automatisch neu)?

Code: Alles auswählen

# killall -9 pulseaudio

[snowy]

meine anfängliche Beschreibung ist falsch, dies war scheinbar eine nicht reproduzierbare Ausnahme.
Bei meinen Tests habe ich nun auch schon die umgekehrte Konstellation erlebt (Admin hört nichts, Desktop-User aber schon).
In wenigen Fälle ist auch nach einem Suspend-to-RAM alles generell okay.

In der Mehrheit der Fälle ist der Ton aber nach Suspend-to-RAM konsequent weg.
Im alten Thread war auch immer ein nicht existenter Kopfhörer angeblich eingesteckt. Nun wird von Pulse-Audio immer als einzige Ausgabe-Einheit eine Dummy-Ausgabe angegeben.

Killall bringt gar nichts. Ebenso ändert die manuelle Eingabe der Root-Befehle (alter Workaround) keine Änderung mehr.
mein derzeitiges Fazit: es ist ein Hardware-/Treiber-Problem und der alte Workaround geht nicht mehr, obwohl er eine zeitlang wirklich super funktioniert hat.

[snowy]

@smutbert, alle Hoffnungen sind auf Dich gerichtet , keine Idee mehr?

[smutbert]

Hab den anderen Thread noch einmal durchgelesen und nichts über die verwendeten Kernelversionen gelesen oder darüber ob es sich im ein Notebook handelt. (Hoffentlich habe ich nichts überlesen.)
Ist es ein Notebook (wenn ja, welches)?
Welchen Kernel verwendest du aktuell?
Weißt du noch welcher es im alten Thread war?
(War es der normale stretch-Kernel oder der aus den backports und bist du noch immer bei stretch?)

Entferne für die weitere Fehlersuche den Workaround aus dem vorigen Thread. Nicht dass der zusätzlich ein Fehlverhalten von Pulseaudio provoziert oä.
und zeig die Ausgabe von

Code: Alles auswählen

$ aplay -l

und zwar einmal vor dem Suspend wenn der Ton noch funktioniert und einmal danach, wenn er gerade nicht funktioniert.

[snowy]

Hi,

also es ist ein schon etwas älterer ASUS Laptop X54HY-SO242V
Aktueller Kernel: Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux

Welchen Kernel ich im alten Thread hatte?
Ganz sicher bin ich mir nicht, aber gemäß Synaptic-Chronik sollte es wohl 4.9.0.4 oder .6 gewesen sein

es sollte eigentlich der normale Stretch-Kernel sein, backports sind zumindest jetzt nicht mehr in den Sourcen eingebunden und waren es wohl nie (aus Erinnerung heraus)

aplay-Ausgabe ist nach Reboot und Suspend immer identisch

Code: Alles auswählen

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC269VB Analog [ALC269VB Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

mit dem Ausbau des bisherigen Workaround sind allerdings nach einem Suspend die unsichtbaren Kopfhörer wieder eingesteckt (wie im alten Thread)

[smutbert]

[…]
mit dem Ausbau des bisherigen Workaround sind allerdings nach einem Suspend die unsichtbaren Kopfhörer wieder eingesteckt (wie im alten Thread)

ist das reprouzierbar so?
(scheint mir immerhin besser als in Pulseaudio nur das Dummy-Gerät zur Verfügung zu haben, auch wenn es nicht viel bringt, wenn man in beiden Fällen nichts hört)

Das einzige was ich bis jetzt gefunden habe ist, dass es bei diesem Audio-Codec in manchen Fällen hilft eine Moduloption zu setzen, zB mit einer »/etc/modprobe.d/audio.conf« mit dem Inhalt

Code: Alles auswählen

options snd-hda-intel model=auto

und eventuell danach

Code: Alles auswählen

# update-initramfs -u

ausführen, nur für den Fall, dass es das Modul aus irgendeinem Grund in die initrd geschafft hat.

Zusätzlich könntest du eigentlich auch gleich den Kernel aus den Backports testen.

[snowy]

Zusätzlich könntest du eigentlich auch gleich den Kernel aus den Backports testen.

peinliche Frage eines kleinen Linux-Lichtes
Auf meinem Laptop habe ich die Stretch-Backports aktiv, aber den gleichen Kernel

meinst Du etwas anderes? Oder verstehe ich es falsch?

Das Setzen von der audio.conf, wie von Dir vorgeschlagen, hat leider keine Änderung gebracht. Nach einem Suspend ist der Ton weiterhin weg

[smutbert]

hm, jetzt versteh ich nix. Zuerst hast du geschrieben

es sollte eigentlich der normale Stretch-Kernel sein, backports sind zumindest jetzt nicht mehr in den Sourcen eingebunden und waren es wohl nie (aus Erinnerung heraus)

und nun schreibst du, die backports sind aktiv?

Jedenfalls hast du Kernel 4.9 und der ist nicht aus den Backports – in den Backports ist 4.18.

Oder falls es daran scheitert, wie man Pakete aus den Backports installiert:
Die Backports erhalten automatisch eine niedrigere Priorität und werden nicht automatisch installiert. Um ein Paket aus den Backports zu installieren, musst du also zuerst die Backports zu den Paketquellen hinzufügen und dann die Paketlisten aktualisieren und das Paket explizit aus den Backports anfordern:

Code: Alles auswählen

# apt update
# apt -t stretch-backports install linux-image-amd64

[snowy]

sorry, sorry, habe mich mißständlich ausgedrückt

mein Laptop ist nicht der problematische Laptop, aber das kannst Du ja nicht wissen.

Und mit den Backports habe ich jetzt verstanden und erfolgreich 4.18 installiert.
Was soll ich sagen, scheinbar löst dieser Kernel (incl. audio.conf-Einstellung) mein Problem, zumindest im Moment ist nach jedem Suspend der Ton weiterhin da

ich werde es weiterhin beobachten....

@smutbert, vielen Dank für Deine Hilfestellung

kleiner unschöner Nebeneffekt des Kernel-Updates, der Gnome-Desktop braucht jetzt nach einem Reboot gefühlt Minuten um zu Starten, aber damit kann ich leben, wenn der Ton nach Suspend aktiv bleibt.

[smutbert]

Macht ja nichts, ich hab mich nur nicht ausgekannt.

Die Moduloption braucht es also mit dem neuen Kernel, damit es funktioniert, aber den alten Workaround mit dem Skript nicht mehr – hab ich das richtig verstanden?

Wegen der Verzögerung könntest du versuchen haveged zu installieren. Nach einem Update trat bei vielen, speziell mit Gnome das Problem auf, dass der Login verzögert wurde bis das System genügend Entropie (Zufallszahlen) im hatte. (haveged sammelt im System zusätzlichen Zufall ein, der die Verzögerung beheben oder mindern sollte.) Hilft das nichts, dann liegt die Ursache wahrscheinlich woanders.

[snowy]

Hi,

sorry für die Antwort-Verzögerung, hatte vorher kein Zugriff auf das Problem-Gerät.

Also habe jetzt auch den Versuch unternommen, ob neuer Kernel aus Backports das Ton-Problem auch ohne den Eintrag in audio.conf löst.
Ja, tut es

Fazit: Kernel debian 4.18.0-0.bpo.1-amd64 löst das Ton-Problem ohne jegliche Zusatz-Mittel, Konfig-Einträge etc.

Danke auch für den Hinweis auf haveged, jetzt startet der Desktop nach Reboot in gewohnt schneller Geschwindigkeit