[Gelöst] ALSA: Audio lässt sich nicht aktivieren

[smutbert]

Ich hoffe, dass es kein allzu großes Problem sein wird, den Fehler zu finden. Wir wissen ja bereits, dass

Code: Alles auswählen

$ aplay -D hw:Generic_1 ~/Downloads/Digital\ Presentation_48000.wav

funktioniert. Wenn du nun nach meinem Vorschlag

Code: Alles auswählen

defaults.ctl.card Generic_1
defaults.pcm.card Generic_1

in der »/etc/asound.conf« oder »~/.asoundrc« stehen hast, sollte der Befehl auch ohne Angabe des Audiogeräts funktionieren

Code: Alles auswählen

$ aplay ~/Downloads/Digital\ Presentation_48000.wav

Tut er das?

(Beim Browser gibt es möglicherweise noch einen Fallstrick, aber ich würde vorschlagen, darum kpmmern wir uns, wenn es sonst einmal grundsätzlich funktioniert.)

@towo
Ich würde zuerst gerne herausfinden, wo der Fehler bis hier besteht, aber wie man hdmi-audio per udev-Regel ausschalten/deaktivieren kann, interessiert mich seitdem du das im anderen Thread geschrieben hast.

[towo]

Code: Alles auswählen

root@Defiant:/home/towo# cat /etc/udev/rules.d/10-remove-nvidia-audio.rules
ACTION=="add", KERNEL=="0000:09:00.1", SUBSYSTEM=="pci", RUN+="/bin/sh -c 'echo 1 > /sys/bus/pci/devices/0000:09:00.1/remove'"

So macht man das per udev rule.

[Livingston]

Wieder was gelernt in meinen alten Tagen: Ich habe bei der Flaschengeistbefragung des Wiki von alsa-project.org und anderen Dokus konsequent jahrelang den Unterschied zwischen smutberts Ansatz

Code: Alles auswählen

defaults.ctl.card Generic_1
defaults.pcm.card Generic_1

und meinem

Code: Alles auswählen

pcm.!default { 
	type hw
	card Generic_1
	device 0
}

ctl.!default {
	type hw
	card Generic_1
}

ignoriert. Steht ja beide Male irgendwie default drin, macht aber was anderes.
Das Sammeln von Informationen zu ALSA kann ganz schön mühselig sein. "Mal eben" nachschlagen ist leider nicht möglich, und wie ich hier sehe, kann man sich problemlos verrennen, wenn man nicht aufpasst.

[mcb]

Firmware-sof ist installiert?

Code: Alles auswählen

firmware-sof | 1.7-1         | stable/non-free   | source
firmware-sof | 2.0-1         | testing/non-free  | source
firmware-sof | 2.0-1         | unstable/non-free | source
marc@mb:~$ apt policy firmware-sof-signed 
firmware-sof-signed:
  Installed: 2.0-1
  Candidate: 2.0-1
  Version table:
 *** 2.0-1 100
        100 /var/lib/dpkg/status
     1.7-1 500
        500 http://debian.inf.tu-dresden.de/debian bullseye/non-free amd64 Packages
        500 http://debian.inf.tu-dresden.de/debian bullseye/non-free i386 Packages

[Blackbox]

Wenn du nun nach meinem Vorschlag

Code: Alles auswählen

defaults.ctl.card Generic_1
defaults.pcm.card Generic_1

in der »/etc/asound.conf« oder »~/.asoundrc« stehen hast, sollte der Befehl auch ohne Angabe des Audiogeräts funktionieren

Sollte, aber es funktioniert nicht.
Ich hatte doch vorhin in der Mittagspause geschrieben, dass ich alle eure Vorschläge durchprobiert habe.

Ich verwende immer noch die Konfigurationsdatei

Code: Alles auswählen

/etc/asound.conf

.

Code: Alles auswählen

$ aplay ~/Downloads/Digital\ Presentation_48000.wav

Tut er das?

Die kurze Version lautet: Nein, das funktioniert nicht.
Die lange Version beinhaltet aber eine Fehlermeldung.

Code: Alles auswählen

ALSA lib conf.c:1240:(parse_value) card is not a string
ALSA lib conf.c:2005:(_snd_config_load_with_include) _toplevel_:2:0:Das Argument ist ungültig
ALSA lib conf.c:4094:(config_file_open) /etc/asound.conf may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:4016:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4623:(snd_config_update_r) hooks failed, removing configuration
aplay: main:831: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig

(Beim Browser gibt es möglicherweise noch einen Fallstrick, aber ich würde vorschlagen, darum kpmmern wir uns, wenn es sonst einmal grundsätzlich funktioniert.)

Gern, obwohl ich noch nicht ahne, worauf du anspielst?
Aber genau, darum kümmern wir uns später.

@towo
Ich würde zuerst gerne herausfinden, wo der Fehler bis hier besteht, aber wie man hdmi-audio per udev-Regel ausschalten/deaktivieren kann, interessiert mich seitdem du das im anderen Thread geschrieben hast.

Dem würde ich mich anschließen.

Code: Alles auswählen

root@Defiant:/home/towo# cat /etc/udev/rules.d/10-remove-nvidia-audio.rules
ACTION=="add", KERNEL=="0000:09:00.1", SUBSYSTEM=="pci", RUN+="/bin/sh -c 'echo 1 > /sys/bus/pci/devices/0000:09:00.1/remove'"

So macht man das per udev rule.

@towo gibt es da nichts Eleganteres; diese udev-Regel sieht aus wie mit dem MG geschnitzt ...

den Unterschied zwischen smutberts Ansatz

Code: Alles auswählen

defaults.ctl.card Generic_1
defaults.pcm.card Generic_1

und meinem

Code: Alles auswählen

pcm.!default { 
	type hw
	card Generic_1
	device 0
}

ctl.!default {
	type hw
	card Generic_1
}

ignoriert.

Ich habe in jedem Falle deinen Lösungsvorschlag nicht ignoriert.

Wieder was gelernt in meinen alten Tagen: Ich habe bei der Flaschengeistbefragung des Wiki von alsa-project.org und anderen Dokus konsequent jahrelang den Unterschied zwischen smutberts Ansatz

Code: Alles auswählen

defaults.ctl.card Generic_1
defaults.pcm.card Generic_1

und meinem

Code: Alles auswählen

pcm.!default { 
	type hw
	card Generic_1
	device 0
}

ctl.!default {
	type hw
	card Generic_1
}

ignoriert. Steht ja beide Male irgendwie default drin, macht aber was anderes.
Das Sammeln von Informationen zu ALSA kann ganz schön mühselig sein. "Mal eben" nachschlagen ist leider nicht möglich, und wie ich hier sehe, kann man sich problemlos verrennen, wenn man nicht aufpasst.

Ja, leider.
Gerade nach dem Job lässt die Konzentration sehr nach.

Steht ja beide Male irgendwie default drin, macht aber was anderes.
Das Sammeln von Informationen zu ALSA kann ganz schön mühselig sein. "Mal eben" nachschlagen ist leider nicht möglich, und wie ich hier sehe, kann man sich problemlos verrennen, wenn man nicht aufpasst.

Genau das macht ALSA so spannend, aber auch, wie gerade in meinem Anwendungsbereich anstrengend.

Firmware-sof ist installiert?

Wenn du nun noch erklären möchtest, wieso eine Intel Firmware auf einem AMD System installiert werden sollte?

Code: Alles auswählen

Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller

Bitte nur auf Themen antworten, die auch verstanden wurden!

[mcb]

Ach so, war ja nur eine Idee ->

Sound Open Firmware For AMD Audio Hardware Arrives, Initially For Renoir ACP - Phoronix:
https://www.phoronix.com/scan.php?page= ... are-Renoir

[Blackbox]

Ach so, war ja nur eine Idee ->

Die genau was gebracht hat?

Sound Open Firmware For AMD Audio Hardware Arrives, Initially For Renoir ACP - Phoronix:
https://www.phoronix.com/scan.php?page= ... are-Renoir

Wie wäre es einmal mit Antworten, die auch zum Thema passen?
Eine Suchmaschine kann ich selbst füttern.

Bitte halte dich zukünftig aus meinen Threads heraus!

[dasebastian]

Ich werfe ganz vorsichtig in den Raum:

Ist tlp installiert? Ich hatte deswegen "Alsaprobleme" mit einer externen Soundkarte, die wurde dann nicht generell mit Strom versorgt, da hat es in der Bedienung und Versorgung geknirscht.

Wird wahrscheinlich nicht der Grund sein, aber wenn installiert, vielleicht mal probieren?

[Blackbox]

Ist tlp installiert?

Die Software eines Ubuntuverstehers?
Mit Sicherheit nicht.

[dasebastian]

Die Software eines Ubuntuverstehers?

??

Sorry.

[Livingston]

Ich steh jetzt ein bissel auf dem Schlauch.
Wir haben ja schon rausbekommen, dass

Code: Alles auswählen

$ aplay -D hw:Generic_1 ~/Downloads/Digital\ Presentation_48000.wav

den Job tut.
Ein Eintrag in der asound.conf (egal, ob rallis, smutberts oder mein Ansatz) sollte aplay automatisch Richtung Generic_1 lotsen und die Angabe -D hw:Generic_1 obsolet machen.

Die graue Theorie besagt, dass die Hammermethode in /usr/share/alsa/alsa.conf (rallis Weg) und smutberts Methode Generic_1 zum default machen (sozusagen einen Link erstellen), während meine Methode default gänzlich neu definiert, womit es ausschließlich auf Generic_1 festgenagelt wird und sonstige schöne automatische Verbindungen wie Mixen, Lautstärkeregelung, etc links liegen lässt. Sollte aber zumindest zeigen, dass es überhaupt funktioniert.

Ideen:
1. Schreibfehler in der asound.conf?
2. Ansatz von ralli mit einem von Smutbert oder mir gemixt, wodurch die Zuweisungen von Generic und Generic_1 zweimal getauscht wurden?

[Blackbox]

Die graue Theorie besagt, dass die Hammermethode in /usr/share/alsa/alsa.conf (rallis Weg) und smutberts Methode Generic_1 zum default machen (sozusagen einen Link erstellen), während meine Methode default gänzlich neu definiert, womit es ausschließlich auf Generic_1 festgenagelt wird und sonstige schöne automatische Verbindungen wie Mixen, Lautstärkeregelung, etc links liegen lässt.

Der konkrete Hinweis auf die

Code: Alles auswählen

/usr/share/alsa/alsa.conf

führte zu dieser ziemlich großen Konfigurationsdatei.

41691
Ich werde diese Datei einmal einem Backup unterziehen und überschreiben.

Sollte aber zumindest zeigen, dass es überhaupt funktioniert.

Eben, deswegen werde ich die vom System erstellte Konfigurationsdatei /usr/share/alsa/alsa.conf einmal austauschen.

Ideen:
1. Schreibfehler in der asound.conf?

Dann müsste aber jemand in meiner Tastatur sitzen, weil ich eure Befehle geschleust durch einen Filter in den Terminal Emulator eingefügt habe.

2. Ansatz von ralli mit einem von Smutbert oder mir gemixt, wodurch die Zuweisungen von Generic und Generic_1 zweimal getauscht wurden?

Nein, die Holzhammermethode wollte ich bis dahin umgehen, wenn es keine andere Möglichkeit mehr gibt.
Diese Situation scheint nun erreicht zu sein.

[smutbert]

Hm, das sieht so aus

Die kurze Version lautet: Nein, das funktioniert nicht.
Die lange Version beinhaltet aber eine Fehlermeldung.

Code: Alles auswählen

ALSA lib conf.c:1240:(parse_value) card is not a string
ALSA lib conf.c:2005:(_snd_config_load_with_include) _toplevel_:2:0:Das Argument ist ungültig
ALSA lib conf.c:4094:(config_file_open) /etc/asound.conf may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:4016:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4623:(snd_config_update_r) hooks failed, removing configuration
aplay: main:831: Fehler beim Öffnen des Gerätes: Das Argument ist ungültig

als ob ich es geschafft hätte in zwei Zeilen einen Fehler einzubauen. Die erste Zeile der Fehlermeldung könnte bedeuten, dass Anführungszeichen notwendig sind, also

Code: Alles auswählen

defaults.ctl.card "Generic_1"
defaults.pcm.card "Generic_1"

(das wäre mir allerdings neu, zumindest bei Namen, die keine verdächtigen Zeichen enthalten und das _ hätte ich als unproblematisch eingestuft)

Sonst könntest du es testweise mit

Code: Alles auswählen

defaults.ctl.card 1
defaults.pcm.card 1

versuchen – da kann es nicht an den Anführungszeichen scheitern.


edit:
Besagte alsa.conf würde ich lassen wie sie ist – manches dürfte sich ohne diese Datei deutlich anders verhalten.

[Livingston]

EDIT:
DISCLAIMER/WARNUNG: Dieser Beitrag ist ein schönes Beispiel, wie ich mit Tomaten vor den Augen fast alles noch komplizierter gemacht hätte. Zum Glück hat blackbox die richtige Lösung verarbeitet (siehe nächster Beitrag).
Wer ein Beispiel für "knapp daneben ist trotzdem für die Tonne" sucht, genieße diesen Post, ansonsten einfach nicht beachten.

Ich hab mich nochmal durch den gesamten Thread gehangelt und festgestellt, dass wir uns alle mit ein paar Fehlerwiederholungen im Kreis gedreht haben.

Ich rekapituliere noch mal: "Generic_1" steht für Karte 0, Gerät 3 und soll die Ausgabe bewerkstelligen, während "Generic" für Karte 0, Gerät 0 steht und nicht verwendet werden soll. Default soll also "hw:0,3" werden. smutbert liefert dafür den einfachsten Ansatz: In der Konfigurationsmatrix von ALSA werden die entsprechenden Werte für "defaults" geändert. Dann muss das aber für alle beteiligten Werte gelten, nicht nur für "card" sondern auch für das "device" Nummer 3 innerhalb der Karte 0.

Um sicherzugehen, dass der String "Generic_1" nicht fehlinterpretiert wird (kann ja sein, dass das "_" Ärger macht), nehme ich also die Nummern aus der Ausgabe von aplay -l, aber nun nicht meinen, sondern smutberts Ansatz:

Code: Alles auswählen

defaults.ctl.!card 0
defaults.pcm.!card 0
defaults.pcm.!device 3

Bleiben noch 2 Anmerkungen:
1. Das "Control-Device" bezieht sich immer auf die gesamte Karte bezieht und daher gehört hier kein Eintrag wie defaults.ctl.device hin. (Kurz und nicht ganz korrekt: Während sich PCM auf die Sounddaten bezieht, dient CTL der Hardwarekontrolle.)
2. Das "!" bedeutet soviel wie: Überschreibe eventuelle Vorgabewerte bedingungslos.

Hab bei mir gerade testweise eine ähnliche Konfiguration von hw:0,0 (HDMI) auf hw:0,2 (Analog) gepolt und es funktioniert.

NACHTRAG:
Hier in https://wiki.gentoo.org/wiki/ALSA#.7E.2F.asoundrc gibt's auch noch ein paar schöne Hinweise.
Auch https://www.volkerschatz.com/noise/alsa.html kann einem gut den Kopf waschen und Licht in ein paar dunkle Ecken bringen.
https://alsa-project.org/wiki/Asoundrc geht leider mit keinem Wort auf die defaults...-Schreibweise ein. Insgesamt ist das Wiki ziemliches Stückwerk, obwohl es von Upstream stammt. Schade!
Das unoffizielle Wiki https://alsa.opensrc.org/ liefert einige gute (aber leider auch nicht alle) wichtigen Stichworte. War wohl mal eine Art FAQ, oder eine aufgearbeitete Mailingliste.

[Blackbox]

Ich bin euch sooooooo dankbar!

Code: Alles auswählen

defaults.ctl.card 1
defaults.pcm.card 1

Diese Konfiguration war die richtige Konfiguration.
Nun wäre noch das dmix Plugin in die nun funktionierte Konfiguration einzubauen.
Oder besser in einen neuen Thread packen?

[Livingston]

Code: Alles auswählen

defaults.ctl.card 1
defaults.pcm.card 1

Diese Konfiguration war die richtige.

Ich raff zwar überhaupt nicht, warum das jetzt geht (Gerät 1 statt 0 ), aber Hauptsache, es klappt.
_____

EDIT: Shame on me, ich erzähl die ganze Zeit was von "hw:0,0", aber gesucht war "hw:1,0". Zeit für Urlaub, bin reif für die Insel.
_____

Ich bin euch sooooooo dankbar!

You're welcome, always a pleasure

[Blackbox]

Ich raff zwar überhaupt nicht, warum das jetzt geht (Gerät 1 statt 0 ), aber Hauptsache, es klappt.

Das geht nicht nur dir so.
Wirklich verstanden habe ich das auch nicht, weil es jeder Logik widerspricht, aber dennoch bin ich froh!

You're welcome, always a pleasure

Oh, I can only return that.

[smutbert]

Mich stört noch ein bisschen, dass es mit der Angabe der Namen der Karte nicht geklappt hat. Namen sind mir immer lieber als Nummern, besonders weil sich die Nummerierung mitunter auch ändern kann. Das mit den Anführungszeichen hast du nicht zufällig noch probiert?

Die Audiowiedergabe mit dem Browser funktioniert auch?

Nun wäre noch das dmix Plugin in die nun funktionierte Konfiguration einzubauen.
Oder besser in einen neuen Thread packen?

Ein eigener Thread sollte dafür nicht notwendig sein, weil das schon erledigt sein müsste.

Alsa verwendet mit seiner Standardkonfiguration (also unter anderem mit der alsa.conf, die du aus dem Weg geräumt hast oder räumen wolltest) bereits dmix, plug und je nach Hardware eventuell noch weitere Plugins.
Mit deiner jetzigen asound.conf hast nur dafür gesorgt, dass der Ton am Ende per default beim richtigen Gerät landet (statt beim nicht vorhandenen Gerät 0 der Karte 0).

@towo
Danke, da muss ich gleich einmal schauen welche Geräte man sonst noch so via sysfs deaktivieren kann ☺

[Blackbox]

Mich stört noch ein bisschen, dass es mit der Angabe der Namen der Karte nicht geklappt hat. Namen sind mir immer lieber als Nummern, besonders weil sich die Nummerierung mitunter auch ändern kann.

Das ist ein interessanter Aspekt, den du hier vorbringst.

Das mit den Anführungszeichen hast du nicht zufällig noch probiert?

Um Missverständnisse vorzubeugen, auf welche Konfiguration beziehst du dich genau, die ich außerdem testen sollte?

Die Audiowiedergabe mit dem Browser funktioniert auch?

Tadellos, im Browser und auch zeitgleich im Onlineradio-Streaming-Client, was dafür spricht, dass dmix bereits funktioniert.

Ein eigener Thread sollte dafür nicht notwendig sein, weil das schon erledigt sein müsste.

Hiermit bestätigt.

Alsa verwendet mit seiner Standardkonfiguration (also unter anderem mit der alsa.conf, die du aus dem Weg geräumt hast oder räumen wolltest) bereits dmix, plug und je nach Hardware eventuell noch weitere Plugins.

Nach deiner Erläuterung habe ich davon abgesehen, die Konfigurationsdatei

Code: Alles auswählen

/usr/share/alsa/alsa.conf

zu ersetzen.
Gibt es in diesem Zusammenhang eine Möglichkeit, dass ich mir alle ALSA Plugins anzeigen, oder auslesen kann?

Mit deiner jetzigen asound.conf hast nur dafür gesorgt, dass der Ton am Ende per default beim richtigen Gerät landet (statt beim nicht vorhandenen Gerät 0 der Karte 0).

Das habe ich verstanden.
Obwohl das alles andere als intuitiv ist.

[smutbert]

Das mit den Anführungszeichen hast du nicht zufällig noch probiert?

Um Missverständnisse vorzubeugen, auf welche Konfiguration beziehst du dich genau, die ich außerdem testen sollte?

Ich meine die Anführungszeichen um "Generic_1", das war dieser Beitrag: viewtopic.php?t=184238&start=15#p1302607

Gibt es in diesem Zusammenhang eine Möglichkeit, dass ich mir alle ALSA Plugins anzeigen, oder auslesen kann?

Du meinst nicht alle, die es auf dem System gibt, sondern, die die per default verwendet werden, richtig?

Ich kenne keine einfache Möglichkeit. Man müsste wohl die entscheidenden Konfigurationsdateien durchgehen, wobei es schon eine Herausforderung ist die entscheidenden überhaupt erst zu finden, weil es doch relativ viele gibt,
Von vornerhein wäre die pcm.default-Definition in »/usr/share/alsa/pcm/default.pcm« entscheidend. Laut der würde, wenn ich das richtig verstehe, plughw verwendet, das wieder in irgendeiner anderen Datei definiert ist und bei dem die Wiedergabe nur einen Umweg über das plug-Plugin machen würde (glaube ich):

Anwendung → plug → hw

plug habe ich schon erwähnt. Das ist ein Plugin, das die eingehenden Audiodaten (falls nötig) in ein Format umwandelt, mit dem das darauffolgende Plugin umgehen kann. Das darauffolgende Plugin ist in dem Fall

hw das eigentlich einfach nur die Soundkarte repräsentiert.



Viele Soundkarten haben aber eigene Konfigurationen, z.B. gibt es für die weit verbreiteten HD Onboardsounds nach dem Standard von Intel die Datei »tt]/usr/share/alsa/cards/HDA-Intel.conf[/tt]« und da ist es noch einmal etwas unübersichtlicher. Da dürfte die Abfolge bei der Wiedergabe etwa so sein

Anwendung → plug → softvol → dmix → hw

softvol ist eine Softwarelautstärkeregelung in Alsa, die einen pcm-Regler nachrüstet, der bei alten Soundkarten so gut wie immer in Hardware bzw. möglicherweise im Treiber vorhanden war und der bei Onboardsounds aber fehlen würde. Der Regler regelt die Lautstärke von Audioausgaben, bei denen die Audiodaten per Software geliefert werden – im Gegensatz z.B. zur Lautstärke von Audiosignalen, die von einem Line-In Eingang o. ä. kommen und einfach an den Ausgang weitergeleitet werden sollen.

dmix und plug kennen wie ja schon.

[Livingston]

Mich stört noch ein bisschen, dass es mit der Angabe der Namen der Karte nicht geklappt hat. Namen sind mir immer lieber als Nummern, besonders weil sich die Nummerierung mitunter auch ändern kann. Das mit den Anführungszeichen hast du nicht zufällig noch probiert?

Die "sprechenden Namen" funktionieren wohl nicht überall.

Ich habe jetzt mal ein wenig an einer meiner Kisten geschaut. Hier ist eine Onboard-Intel-HDA und eine Nvidia-GTX-1070, die nur HDMI verarzten kann verbaut. aplay -l sagt:

Code: Alles auswählen

**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC1150 Analog [ALC1150 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
Karte 0: PCH [HDA Intel PCH], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 8: HDMI 2 [HDMI 2]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 9: HDMI 3 [HDMI 3]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 10: HDMI 4 [HDMI 4]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 9: HDMI 3 [HDMI 3]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 10: HDMI 4 [HDMI 4]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 11: HDMI 5 [HDMI 5]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 12: HDMI 6 [HDMI 6]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Habe dann mit 3 Versionen von .asoundrc die Ausgabe auf HDMI getestet und dafür jeweils audacious ohne Parameter gestartet.

Code: Alles auswählen

pcm.!default {
       type hw
       card NVidia
       device 7
}


ctl.!default {
       type hw
       card NVidia
}

Funktioniert, spielt hörbar Sound ab.

Code: Alles auswählen

defaults.pcm.card NVidia
defaults.pcm.device 7
defaults.ctl.card NVidia

Klappt nicht: ALSA error: snd_pcm_open failed: Das Argument ist ungültig.

Code: Alles auswählen

defaults.pcm.card 1
defaults.pcm.device 7
defaults.ctl.card 1

Funktioniert, spielt hörbar Sound ab.

EDIT: NACHTRAG
Das zweite Beispiel hab ich auch noch mal mit Anführungszeichen getestet und das klappt auch nicht. Auf der Konsole antwortet audacious mit:

Code: Alles auswählen

$ audacious
ALSA lib conf.c:1229:(parse_value) card is not a string
ALSA lib conf.c:1970:(_snd_config_load_with_include) _toplevel_:1:26:Das Argument ist ungültig
ALSA lib conf.c:3817:(config_file_open) /home/lstone/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:3739:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4203:(snd_config_update_r) hooks failed, removing configuration
ERROR alsa.cc:570 [open_mixer]: snd_mixer_attach failed: Das Argument ist ungültig.

Will man dann trotzdem was aus der Playingliste abspielen folgt noch:

Code: Alles auswählen

ALSA lib conf.c:1229:(parse_value) card is not a string
ALSA lib conf.c:1970:(_snd_config_load_with_include) _toplevel_:1:26:Das Argument ist ungültig
ALSA lib conf.c:3817:(config_file_open) /home/lstone/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:3739:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4203:(snd_config_update_r) hooks failed, removing configuration
ALSA lib conf.c:1229:(parse_value) card is not a string
ALSA lib conf.c:1970:(_snd_config_load_with_include) _toplevel_:1:26:Das Argument ist ungültig
ALSA lib conf.c:3817:(config_file_open) /home/lstone/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:3739:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4203:(snd_config_update_r) hooks failed, removing configuration
ALSA lib conf.c:1229:(parse_value) card is not a string
ALSA lib conf.c:1970:(_snd_config_load_with_include) _toplevel_:1:26:Das Argument ist ungültig
ALSA lib conf.c:3817:(config_file_open) /home/lstone/.asoundrc may be old or corrupted: consider to remove or fix it
ALSA lib conf.c:3739:(snd_config_hooks_call) function snd_config_hook_load returned error: Das Argument ist ungültig
ALSA lib conf.c:4203:(snd_config_update_r) hooks failed, removing configuration
ERROR util.cc:269 [audgui_simple_message]: ALSA error: snd_pcm_open failed: Das Argument ist ungültig.

Bug?
____________________

EDIT Nr. 2: Doppelpost integriert

Es hat mir keine Ruhe gelassen. Ich wurde dann hier fündig: https://wiki.archlinux.org/title/Advanc ... ts%22_node
Insbesondere dieser Hinweis:

Code: Alles auswählen

defaults.pcm.!card "SB"; # The override operation mode is necessary here, because of
defaults.ctl.!card "SB"; # different value types.

Also ran an den Speck in meiner eigenen .asoundrc:

Code: Alles auswählen

defaults.pcm.!card "NVidia"
defaults.pcm.device 7
defaults.ctl.!card "NVidia"

Und siehe da: Es klappt!

[smutbert]

Danke für das Ausprobieren. Bei meinen Soundkartennamen hat es bis jetzt immer auch ohne Anführungszeichen funktioniert.

Das heißt dann wohl, dass es bei Blackbox mit

Code: Alles auswählen

defaults.ctl.card "Generic_1"
defaults.pcm.card "Generic_1"

ebenfalls funktionieren sollte.

[Livingston]

Das heißt dann wohl, dass es bei Blackbox mit

Code: Alles auswählen

defaults.ctl.card "Generic_1"
defaults.pcm.card "Generic_1"

ebenfalls funktionieren sollte.

Genau das ist nicht sicher der Fall. Ich hab mal nen Blick in die ALSA-API geworfen, und die besagt, dass der Wert von defaults.pcm.card entweder ein String oder ein Integer ist. Je nach Mondphase und Vogelflug ist das meist der Integer-Wert 0. Will man defaults.pcm.card dann selbst einen String zuweisen, gibt's die Fehlermeldung, es sei denn man nutzt die Override-Option "!"; dann wird der vorherige Eintrag komplett gelöscht und neu aufgebaut.
Frag mich nicht nach den Hintergründen, das Lesen des Projekt-"Wikis" ist schon Qual genug.
Seiteneffekte habe ich bei Verwendung von "!" noch nicht bemerkt.

Auf jeden Fall kann man festhalten, dass mit Anführungszeichen sicher ein String zugewiesen wird. Hier droht eine neue Stolperfalle: "0" wäre ein String, 0 ein Integer.
Zum Thema, dass man auch Umgebungsvariablen benutzen/auswerten kann, um Defaults (und andere Dinge) festzunageln, mache ich lieber einen neuen Thread auf

Hier etwas zu den vordefinierten defaults:
https://www.sabi.co.uk/Notes/linuxSound ... tructNames
Das noch mal zu den Fallstricken mit der Typenänderung String<->Integer
https://wiki.archlinux.org/title/Advanc ... ts%22_node
alsa-project hat auch was dazu zu sagen, aber die Stelle finde ich auf Anhieb nicht wieder.

[smutbert]

Alsa treibt mich noch in den Wahnsinn und die Rufzeichen in deinem Beitrag habe ich zuerst gesehen und bis zum Schreiben meines Beitrages wieder vergessen

Bis zu deinem letzten Beitrag habe ich die Bedeutung des ! offensichtlich (leicht☺) mißverstanden.
Außerdem habe ich gedacht, das Zuweisen des Strings scheitert daran, dass bereits irgendeine Variable oder sonst irgendein Objekt (in deinem Fall mit dem Namen NVidia, bei Blockbox mit Generic_1 existiert) und man deswegen die Anführungsstriche braucht, damit es als String verstanden wird.

bleibt für mich aber noch die Frage warum es bei mir immer ohne Anführungs- und Rufzeichen funktioniert hat – der default-Wert war bei mir bestimmt auch ein Integer (0).

Wenigstens ist das mit den Variablen ist nichts Neues für mich – das habe ich irgendwo in einem Thread im Debianforum auch schon beschrieben (glaube ich, vielleicht).
Danke für die Detektivarbeit.

[Livingston]

bleibt für mich aber noch die Frage warum es bei mir immer ohne Anführungs- und Rufzeichen funktioniert hat – der default-Wert war bei mir bestimmt auch ein Integer (0).

Hattest Du bei dem Test auf Deinem Rechner bereits eine laufende ALSA-Konfiguration und darin die andere default-Zuweisung

Code: Alles auswählen

pcm.default <String>

im Einsatz? Die unterliegt anscheinend nicht der o.g. Beschränkung. Wenn Du danach mit

Code: Alles auswählen

defaults.pcm.card <String>

drüberbrätst, taucht bei der anhängigen automatischen Bearbeitung der Node kein Typenwechsel auf. -> Friede, Freude, Eierkuchen!

Wäre ja schön, wenn da zumindest teilweise ein logisches Konzept zu erkennen wäre.

Fällt mir am Ende nur noch ein Zitat von der oben genannten Seite https://www.sabi.co.uk/Notes/linuxSoundALSA.html ein (ganz unten auf der Seite unter "Colophon"):

Thanks to the ALSA authors for writing the software, which is after all a huge improvement on OSS, and "thanks" to them also for under-documenting and over-complicating it gleefully probably to protect their own jobs and their employer from competition (really?), and thus giving me the motivation to spend a lot of time, that maybe I could have spent more usefully, trying to collate obscure hints here and there, reverse engineering the sources, and experimenting, to gather the information condensed in these notes.

_________

EDIT: Nachtrag

And now to something completely different -> Eine Antwort auf Blackbox' Frage:

Gibt es in diesem Zusammenhang eine Möglichkeit, dass ich mir alle ALSA Plugins anzeigen, oder auslesen kann?

Der Weg durch die Plugins, Slaves, etc. bis zur Hardware lässt sich zumindest teilweise verfolgen, wenn Du aplay beim Abspielen mit der Option -v aufrufst:

Code: Alles auswählen

$aplay -v ${irgendeine wav-Datei}

Ohne Dateiangabe geht's übrigens nicht, da aplay davon ausgeht, dass der konkrete Weg durch die automatischen oder selbst definierten Plugins für eine gegebene Situation gesucht wird. Man kann auch ohne Hintergrundwissen anhand der Veränderung der ausgebenen Werte bei jedem Schritt sehen, was sich jeweils tut (Anpassung der Samplingraten, Formate, Runterkürzen von mehreren auf 2 Ausgabekanäle etc.). Je nach Samplingrate oder Codecs für verschiedene wav-Dateien, werden auch unterschiedliche Plugins aktiviert.
Such am Besten mal unter den Begriffen "wav Beispiele" oder "wav examples" nach unterschiedlichen wav-Formaten, also z.B. Mono-, Stereo-, Surround-Sound oder verschiedenen Samplingraten. Sortierte Sammlungen solcher Dateien lassen sich leicht finden.

Und noch was gefunden: Der Aufruf von aplay -L (großes L), liefert Dir neben der Hardware auch eine Liste vordefinierter Plugins und virtueller Geräte, z.B. sorround51, was das Umrechnen zwischen einfachem Stereo und Surround5.1 ermöglicht. Das sind nicht unbedingt alle; es hängt vor allem davon ab, welche ALSA-Pakete und -Module Du installiert hast.