Sound beim Systemstart stumm geschaltet

[fischig]

Nach dem upgrade von buster auf bullseye an einer Maschine stelle ich fest, dass der Ton defaultmäßig stummgeschaltet ist.
Auf dem System wird nur openbox, kein systemd, kein udev und kein pulseaudio benutzt.
Ob's relevant ist, kann ich nicht beurteilen, aber ich führ's mal vorsichthalber an:
In /etc/rc.local ist ein script angegeben (schon vor bullseye)mit diesem Inhalt:

Code: Alles auswählen

/bin/chown .audio /dev/snd/*
/bin/chmod 0660 /dev/snd/*

Das scheint auch zu funktionieren, wenn ich die die Dateirechte kontrolliere. Die Lautstärke lässt sich nach dem Start auch wie gewünscht vom User via Mixer-Software einstellen, aber beim Booten ist sie halt unerwünschterweise erst mal stummgeschaltet. Jemand eine Idee, wie das zu ändern wäre?

[fischig]

zusatzlich:

Code: Alles auswählen

amixer sset Master unmute 100%

löst das Problem. Man kann auch weniger als 100% angeben, aber ohne ein %-Angabe wird hier zwar die Stummschaltung aufgehoben, aber der Hauptregler steht dann bei 0.

[pferdefreund]

Alsa-Utils installieren. Die sichern die Einstellung des Mixers beim shutdown und restoren das beim Start wieder. Bei mir schon sei Jahren.

[fischig]

Das kann's nicht sein. alsa-utils war installiert. Das Phänomen trat ziemlich sicher bis buster nicht auf (ist nicht meine Maschine).

[smutbert]

Eigentlich sollte das init-Skript, das im Paket alsa-utils ist (»/etc/init.d/alsa-utils«), die Stellung der Lautstärkeregler und auch der Schalter beim Herunterfahren speichern und beim Start wiederherstellen. Das Skript ist aber wie mir scheint mit der Zeit immer komplexer geworden.

Du könntest einmal prüfen ob das Skript funktioniert, wenn das System bereits läuft, also:

1. Code: Alles auswählen

   # /etc/init.d/alsa-utils stop

   (sollte die Lautstärkewerte speichern)
2. dann einen Lauststärkeregler oder Schalter in alsamixer verändern und schließlich

3. Code: Alles auswählen

   # /etc/init.d/alsa-utils start

Danach sollten die Regler wieder auf dem ursprünglichen Wert stehen und speziell wenn das nicht der Fall ist könnten eventuelle Fehlermeldungen auf die Fehlerursache hinweisen.



Wenn es für dich ok ist, dass das init-Skript nicht funktioniert, dann könntest du auch einfach die Regler so einstellen, wie du sie gerne nach dem Systemstart hättest, einmal

Code: Alles auswählen

# alsactl store

ausführen und danach bei jeden Systemstart, zB in der rc.local

Code: Alles auswählen

alsactl restore

ausführen.

[fischig]

Danke für dein Hinweise!
Ich habe schon einen workaraound via amixer.
Die Rechtevergabe für /dev/snd/* funktioniert ohne udev ja auch nicht. All das habe ich mir in eine snd.conf geschrieben, die ich via rc.local ausführen lasse.

Nichtsdestotrotz, werde ich selbstverständlich eine Anregung von smutbert umsetzen! Ich lern' gerne! Aber morgen erst.

[fischig]

Hmm,
Das script scheint gar nicht zu laufen. Ich hatte ein Video mit audio in mpv gestartet (Wie man etwas mit *.wav ohne audiovisuelle Anwendungssoftware macht, kann ich mir schlecht merken, darein muss ich mich jedesmal neu vertiefen). Mit vlc gleicher Effekt.

Code: Alles auswählen

# /etc/init.d/alsa-utils stop
Shutting down ALSA...done.

Ich erwartete, dass die Tonausgabe stoppt. War aber nicht so, der Ton lief munter weiter. Ich habe dann meine amixer-Zeile aus meinem rc.local-script rausgenommen und das System neu gestartet. Video gestartet, Ton stumm. Ton via qasmixer eingeschaltet,

Code: Alles auswählen

# /etc/init.d/alsa-utils stop

, gleicher Effekt.

alsa-utils: pastebin/?mode=view&s=41512 (die einleitenden Kommentare habe ich weggelassen)

[smutbert]

Die Ausgabe

Shutting down ALSA...done.

ist sehr missverständlich und vielleicht habe ich mich auch nicht ganz klar ausgedrückt. Das einzige was der Befehl »/etc/init.d/alsa-utils stop« macht, ist die momentan eingestellten Lautstärkewerte und Schalterstellungen zu speichern, ich glaube in der Datei »/var/lib/alsa/asound.state«.
An einer laufenden oder danach gestarteten Audiowiedergabe sollte sich dadurch gar nichts ändern.

Sinn und Zweck ist, dass die zuletzt eingestellten Lautstärkewerte, beim nächsten Systemstart oder durch Ausführen von »/etc/init.d/alsa-utils start« oder »alsactl restore« wiederhergestellt werden.


Mit den 3 Punkten meines vorigen Beitrags wollte ich lediglich testen ob das Skript »/etc/init.d/alsa-utils« auf deinem System überhaupt korrekt funktioniert. Die beiden alsactl-Befehle sollten es aber eigentlich auf jeden Fall tun.

[fischig]

Gut, dann auf ein Neues.

Zu Beginn der Testreihe läuft meine amixer Zeile: Lautstärke bei, sagen wir, 70%. Ist das ok, oder stört's den Test? (Wenn ich's nicht laufen lasse, ist, der Ton garantiert bereits am Anfang stumm geschaltet.)

[fischig]

Stummschaltung in alsamixer aufgehoben und Lautstärke auf 63% gestellt, alsa_utils gestoppt. Lautstärke als user im alsamixer auf 100% gestellt. alsa-utils gestartet. Lautstärke fällt wieder auf 63% zurück mit dieser Meldung:

Code: Alles auswählen

# /etc/init.d/alsa-utils start
Setting up ALSA...warning: 'alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR= restore' failed with error message 'alsactl: set_control:1461: Cannot write control '2:0:0:Independent HP:0' : Device or resource busy'...done.

edit:
Trotz meiner bescheidenen Kenntnisse fände ich gerne die Ursache des Fehlers. Auch wenn ihn möglicherweise eine alsactl restore behebt.

[smutbert]

Jetzt wissen wir zumindest, dass das Skript grundsätzlich funktioniert, auch wenn es eine Warnung ausgibt. HP dürfte für Headphones, also einen Kopfhörerausgang stehen, aber um dessen Stummschalter, falls er überhaupt einen eigenen hat, geht es ja offensichtlich gar nicht sondern um den Stummschalter, der zum Master-Regler gehört.

Das hier

[...] Man kann auch weniger als 100% angeben, aber ohne ein %-Angabe wird hier zwar die Stummschaltung aufgehoben, aber der Hauptregler steht dann bei 0.

bedeutet außerdem, dass beim Booten nicht nur der Stummschalter nicht sondern auch der Wert des Masterreglers nicht wiederhergestellt wird.

Als nächstes wären die Meldungen von alsa-utils aus dem Syslog vom Herunterfahren und vor allem vom Booten interessant.

[fischig]

Als nächstes wären die Meldungen von alsa-utils aus dem Syslog vom Herunterfahren und vor allem vom Booten interessant.

Hmmm,
Ungeübt. Ich habe es mal direkt nach dem Hochfahren des OS mit

Code: Alles auswählen

cat /var/log/syslog | grep alsa

versucht. Keine Meldung. Dann habe ich aus /var/log/syslog die zeitmäßig letzten Meldungen (313) in eine Textdatei kopiert und bin die von Hand durchgegangen, die Zeichenkette „alsa“ taucht da auch nicht auf. Ich finde lediglich etwas bei „snd“:

Code: Alles auswählen

Nov  4 09:03:37 tux2 kernel: snd_hda_intel 0000:00:1b.0: probe_mask set to 0x1 for device 17aa:20ac
...
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0: autoconfig for AD1984: line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:    hp_outs=1 (0x11/0x0/0x0/0x0/0x0)
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:    mono: mono_out=0x0
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:    dig-out=0x1b/0x0
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:    inputs:
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:      Internal Mic=0x15
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:      Mic=0x14
Nov  4 09:03:37 tux2 kernel: snd_hda_codec_analog hdaudioC0D0:      Dock Mic=0x1c
Nov  4 09:03:37 tux2 kernel: usb 2-5: new high-speed USB device number 3 using ehci-pci
Nov  4 09:03:37 tux2 kernel: input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9
Nov  4 09:03:37 tux2 kernel: input: HDA Intel Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input10
Nov  4 09:03:37 tux2 kernel: input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input11

Fehler sehe ich da nicht.

[smutbert]

Das ist überraschend, ich hätte erwartet, dass zumindest diese Meldung aus deinem Versuch

Code: Alles auswählen

warning: 'alsactl -E HOME=/run/alsa -E XDG_RUNTIME_DIR= restore' failed with error message 'alsactl: set_control:1461: Cannot write control '2:0:0:Independent HP:0' : Device or resource busy'

im Log auftaucht.

Das init-Skript alsa-utils ist aber aktiviert?

[fischig]

Das init-Skript alsa-utils ist aber aktiviert?

Tut mir leid, dass ich wieder mit meinem Halbwissen glänzen muss, aber wie kontrolliere/aktiviere ich das? (Das script steht ausführbar in /etc/init.d/)

Ich werde wohl heute nicht mehr dazu kommen. Unser Chorbetrieb läuft seit Februar 2020 wieder an und ich muss mich um den Notensatz kümmern.

[smutbert]

Ich habe gehofft, dass du das weißt, ich kann mich kaum noch erinnern wie das vor systemd war

Es gibt unter »/etc/rc?.d« symbolische Links zu den init-Skripten. Das ? steht für den Runlevel und wenn der Name mit K beginnt, sorgt der Link für das Beenden (Kill) des Dienstes und mit S wird er gestartet. Normalerweise schlägt man sich nicht direkt mit den symbolischen Links herum sondern verwendet zum Beispiel den Befehl update-rc.d um die init-Skripte zu (de)aktivieren, aber ich bin mit den init-Skripten sehr ungeübt und da interessiert mich welche Links es auf deinem System gibt, also zB die Ausgabe von

Code: Alles auswählen

ls -l /etc/rc?.d/*alsa-utils

[fischig]

ich kann mich kaum noch erinnern wie das vor systemd war

Schwante mir schon, dass wir da landen!

In /etc/rc.d/ hatte ich schon reingeguckt.Und soviel kann ich schon sagen: Einen Link auf alsa-utils gibt's darin nicht. Sicher damit etwas anzufangen, wusste ich nicht (Halbwissen halt! ).

Ich habe gerade mal nachgesehen. Falls bei der Sicherung des vorherigen busters auf der Maschine (¹, ²) nicht doch etwas schief gelaufen ist: dort steht alsa-utils auch in /etc/init.d/ und es existiert kein LInk darauf unter /etc/rc*.d/ Und trotzdem meint meine Frau, dass der Sound immer dagewesen sei.

¹ viewtopic.php?t=182485
² viewtopic.php?t=182516

[smutbert]

In »/etc/rc.d/« liegen (bei anderen Distributionen) nur die init-Skripte, die bei Debian in »/etc/init.d« sind. Soweit ich weiß ist also »/etc/rc.d/« unter Debian uninteressant.

Interessant sind rc0.d - rc6.d und da überrascht es mich, dass du keinen symbolischen Link findest. Wenn die Links einen ungewöhnlichen Namen haben, was zumindest theoretisch möglich ist, müssten sie sich mit

Code: Alles auswählen

$ ls -l /etc/rc?.d/* | grep alsa-utils

finden lassen.
Taucht auch da nichts auf, müsstest du das Skript aktivieren. Das ist jetzt der Teil, an den ich mich nicht so wahnsinnig gut erinnern kann (oder nie so richtig gewusst habe), aber ich denke das sollte sich mit

Code: Alles auswählen

# update-rc.d alsa-utils defaults

machen lassen.

[fischig]

Soweit ich weiß ist also »/etc/rc.d/« unter Debian uninteressant.
Interessant sind rc0.d - rc6.d

Letzteres meinte ich! /etc/rc.d/ finde ich ich gar nicht in meinen Debianen. Ich werde deine Vorschläge umsetzen. Aber wie gesagt, wenn ich die nötige Zeit finde, um allfällige Fehler finden und korrigieren zu können. Nochmal drei Tage Lahmlegen des „weiblichen“ Rechners möchte ich tunlichst vermeiden!

Wir könnten dann auch noch diskutieren, wie man das jetzt mit openrc (als Alternative zu systemd) gestaltet.

[fischig]

Ich habe wohl nicht gründlich genug nachgeguckt.

buster:

Code: Alles auswählen

$ ls -l /etc/rc?.d/* | grep alsa-utils
lrwxrwxrwx 1 root root  20 Nov 25  2011 /etc/rc0.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root  20 Nov 25  2011 /etc/rc1.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root  20 Nov 25  2011 /etc/rc6.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root  20 Okt 25  2017 /etc/rcS.d/S16alsa-utils -> ../init.d/alsa-utils

bullseye (System-Platte unter /etc/usb eingehängt):

Code: Alles auswählen

$ ls -l /media/usb/etc/rc?.d/* | grep alsa-utils
lrwxrwxrwx 1 root root 20 Nov 25  2011 /media/usb/etc/rc0.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root 20 Nov 25  2011 /media/usb/etc/rc1.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root 20 Nov 25  2011 /media/usb/etc/rc6.d/K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root 20 Okt 30 17:19 /media/usb/etc/rcS.d/S15alsa-utils -> ../init.d/alsa-utils

Offenbar genau die gleiche Konfiguration?

[katzenfan]

Schon mal im Bios nachgesehen? Vielleicht ist's da ja so eingestellt, daß es erst bei individueller Anforderung durch das gestartete System aktiviert wird?

[smutbert]

Hier hat sich auch noch nichts geändert, oder?

Mir gehen hier langsam die Ideen aus, denn es existiert wie üblich ein init-Skript, das die Lautstärke/Stummschalter beim Herunterfahren speichern und beim Systemstart wiederherstellen sollte und das ist auch aktiviert. Manuell aufgerufen erledigt das Skript seine Arbeit offensichtlich auch korrekt, aber beim Systemstart und vermutlich auch beim Herunterfahren scheint das Skript nicht zu funktionern und es finden sich keine Meldungen über ein Scheitern im Log.

Manuell nach dem Systemstart aufgerufen scheint das Skript seine Arbeit ja korrekt zu erledigen und beim automatisch gestartet sollte es laut deinem letzten Beitrag auch werden. Du findest aber auch keine Meldungen im Log über ein Scheitern.

Siehst du bei deinem System die Statuszeilen vom Starten und Beenden der Dienste beim Systemstart und beim Herunterfahren?
Wenn ja, bei diesem Skript sollte die Zeile mit „Setting up ALSA“ beginnen und bei einem Fehler danach irgendetwas mit Warning oder Error folgen – so etwas ist dir bis jetzt auch noch nie aufgefallen?

Der einfachste Workaround wäre jedenfalls eine Zeile

Code: Alles auswählen

/usr/sbin/alsactl restore

in der »/etc/rc.local«

[fischig]

Ich habe schon gar nicht mehr daran gedacht. ich lass' es wohl bei meiner amixer-Zeile in der rc.local. Das genügt unseren Bedürfnissen. Ansosnten müsste ich wohl zum Vergleichen das alte buster wieder einbauen.

[hikaru]

Ansosnten müsste ich wohl zum Vergleichen das alte buster wieder einbauen.

Nur so als Idee für die Zukunft:
Ich habe immer zwei um ein Release versetzte Systeme parallel. Bei jedem Releasewechsel wird das Ältere der beiden mit dem neuen Release überschrieben und wird zur produktiven Installation.
Das nimmt den Druck, falls etwas im neuen Release nicht auf Anhieb klappt, bietet eine schnelle Möglichkeit um nochmal nachzuschauen was früher war und nebenbei fällt ein (meist etwas angestaubtes) Backupsystem ab.

[mcb]

Ansosnten müsste ich wohl zum Vergleichen das alte buster wieder einbauen.

Nur so als Idee für die Zukunft:
Ich habe immer zwei um ein Release versetzte Systeme parallel. Bei jedem Releasewechsel wird das Ältere der beiden mit dem neuen Release überschrieben und wird zur produktiven Installation.
Das nimmt den Druck, falls etwas im neuen Release nicht auf Anhieb klappt, bietet eine schnelle Möglichkeit um nochmal nachzuschauen was früher war und nebenbei fällt ein (meist etwas angestaubtes) Backupsystem ab.

Das heißt ich würde mir jetzt z.B. bullseye und testing als Dualboot einrichten? Da brauche ich erstmal eine größere SSD. Oh no. Ich wollte den Schwarzen Freitag doch eigentlich boykotieren.