Vor etwa 2 Jahren hatte ich in diesem Blog mehrere Artikel zur Einrichtung der Xonar D2X unter Linux – genauer unter Opensuse 13.1 (mit KDE) – verfasst. Ein Fazit war, dass Pulseaudio für diese Karte nicht vernünftig funktionierte. Zumindest dann nicht,
- wenn man Stereo-Signale auf mehrere Ausgangskanäle upmixen will
- und wenn man seine relativen Volume-Einstellungen für die verschiedenen analogen Ausgangskanäle nicht ständig bei Lautstärke-Änderungen unter dem Mixer von “pavucontrol” verlieren will.
Die Karte selbst nimmt keinen Mix auf N.1-Ausgabe-Systeme vor; das direkt unterstützte Mixing blendet den Center und Bass-Speaker aus.
Die Xonar D2X läuft bei mir inzwischen unter Leap 42.1. Dass der Pulseaudio-Layer mit pavucontrol als Mixer trotz diverser optischer Aufbesserungen inzwischen besser mit Mehrkanalkarten umgehen könne, sehe ich nicht. Ich bleibe dabei: Pulseaudio schafft mehr Probleme als es löst. Das liegt weniger an der Idee eines auf Alsa und anderen Soundsystemen aufsetzenden Zwischenlayers als an der schlechten Umsetzung dieses Layers für verschiedene Karten – im besonderen Multikanal-Karten. Problematisch ist dabei, dass für eine evtl. mögliche Reproduktion der Mixing- und PCM-Plugin-Optionen von Alsa unter Pulseaudio aus meiner Sicht erhebliche Detailkenntnisse von Pulseaudio erforderlich sind. Ganz schlimm wird es nach meiner Erfahrung dann, wenn das System mehrere Multikanal-Soundkarten enthält.
Im letzten meiner Artikel zur D2X
Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1
hatte ich eine Muster-Datei “~/.asoundrc” für das Upmixing von Stereo-Eingangssignalen angegeben und die völlige Deaktivierung von Pulseaudio empfohlen. Über die “.asoundrc” wurde auch ein SW-Volume-Regler angelegt, um für alle Quellen und über alle Output-Kanäle der D2X hinweg die Lautstärke regeln zu können, ohne die relative Laustärke-Gewichtung der Kanäle zueinander zu verändern.
Probleme mit Firefox und mit KDE5
Leider verlassen sich offenbar immer mehr Entwickler auf ein laufendes Pulseaudio – so schlecht das auch sein mag. Das führt dann bei denjenigen, die aus guten Gründen nur mit Alsa arbeiten wollen, zu mehr oder weniger großen Problemen. Ein schlimmer Bug ist aus meiner Sicht der, dass z.B. unter KDE 5 (unter OS Leap 42.1) von bei mir über 20 verfügbaren HW und virtuellen PCM Alsa-Devices nur noch genau eines angezeigt wird, wenn Pulseaudio deaktiviert ist (s. https://bugs.kde.org/show_bug.cgi?id=362476). Dennoch sind die Devices da und aktiv – wie etwa die Device Übersichten unter Amarok oder VLC beweisen.
Richtig übel wurde es aber, als Firefox [FF] plötzlich keinen Sound mehr ohne Pulseaudio zu liefern schien.
Auch ein Leser, der meinen Vorschlägen aus dem oben genannten Artikel gefolgt ist, ist nun über dieses Problem gestolpert, dass auch mich schon seit einiger Zeit geplagt hat:
https://wiki.gentoo.org/wiki/ALSA und dort den Bereich “Troubleshooting” oder auch https://bbs.archlinux.org/viewtopic.php?id=186650.
Bei mir dagegen war das Problem mit FF anders gelagert. Vielleicht helfen die nachfolgenden Ausführungen deshalb auch dem einen oder anderen Leser weiter, der sein Firefox-Problem bislang nicht lösen konnte.
Ausgangssituation mit der Xonar D2X als primärer Soundkarte
In meinem aktuellen Arbeitsplatzsystem befinden sich mehrere Soundkarten. Ich befasse mich in diesem Artikel aber nur mit dem Fall, dass lediglich die Xonar D2X als primäre Karte genutzt wird. Unter Opensuse (in meinem Fall in der Version Leap 42.1) kann man die Grundeinrichtung etwa mit YaST vornehmen:
Mit Hilfe der Funktionalität von YaST’s Sound-Einrichtung deaktivieren wir zudem das Pulseaudio-System mittels entsprechender Optionen unter dem Button “Andere” >> “Pulseaudio-Konfiguration” vollständig. (Unter anderen Linux-Varianten sind zur Deaktivierung von Pulseaudio andere Schritte erforderlich). Danach sichern wir die Einstellungen und starten das System neu.
Die explizite Einrichtung der D2X mittels YaST bewahrt uns ggf. noch nicht zwingend vom Laden weiterer Kernelmodule und Treiber für andere Soundkarten durch udev. Wir müssen daher für die nachfolgenden Alsa-Einstellungen prüfen, an welcher Position die D2X unter den verschiedenen Soundkarten tatsächlich erkannt wird.
Die grundsätzlich verfügbaren Karten zeigen folgende Befehle; die D2X ist u.a. als “C-Media Electronics Inc CMI8788 [Oxygen HD Audio]” unter den PCI-Devices erkennbar.
me@mysystem:~> aplay -l | grep Karte rmo@rux:/proc/asound> aplay -l | grep Karte Karte 0: D2X [Xonar D2X], Gerät 0: Multichannel [Multichannel] Karte 0: D2X [Xonar D2X], Gerät 1: Digital [Digital] Karte 1: PCH [HDA Intel PCH], Gerät 0: ALC1150 Analog [ALC1150 Analog] Karte 1: PCH [HDA Intel PCH], Gerät 1: ALC1150 Digital [ALC1150 Digital] Karte 2: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0] Karte 2: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1] Karte 2: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2] Karte 2: NVidia [HDA NVidia], Gerät 9: HDMI 3 [HDMI 3] Karte 3: XFi [Creative X-Fi], Gerät 0: ctxfi [Front/WaveIn] Karte 3: XFi [Creative X-Fi], Gerät 1: ctxfi [Surround] Karte 3: XFi [Creative X-Fi], Gerät 2: ctxfi [Center/LFE] Karte 3: XFi [Creative X-Fi], Gerät 3: ctxfi [Side] Karte 3: XFi [Creative X-Fi], Gerät 4: ctxfi [IEC958 Non-audio]
und
root:~ # lspci -nn | grep Audio 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31) 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fba] (rev a1) 02:00.0 Audio device [0403]: Creative Labs EMU20k2 [X-Fi Titanium Series] [1102:000b] (rev 03) 04:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788]
Nach der Konfiguration der D2X mit YaST und einem Neustart des Systems finden wir unter Opensuse folgenden Eintrag in der Datei “/etc/modprobe.d/50-sound.conf” vor:
options snd slots=snd-virtuoso # rChK.j3r564qQSgF:Virtuoso 200 (Xonar D2X) alias snd-card-0 snd-virtuoso
Wir lassen diesen Eintrag unverändert.
Die aktuell gültige Reihenfolge der Karten ist auch wie folgt erkennbar:
me@mysystem:~> cat /proc/asound/cards
0 [D2X ]: AV200 - Xonar D2X
Asus Virtuoso 200 at 0xd000, irq 16
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xdf640000 irq 146
2 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xdf080000 irq 17
3 [XFi ]: SB-XFi - Creative X-Fi
Creative X-Fi 20K2 Unknown
Die D2X wird also von ALSA definitiv als erste Soundkarte (mit der Nummer 0) verwendet – was immer udev sonst entdeckt und an Modulen nachgeladen haben mag. Wäre dies nicht der Fall, hätten wir dies in der Datei “/etc/modprobe.d/50-sound.conf” durch Festlegung von “index”-Parameter-Werten für die Module festlegen müssen (s. hierzu etwa https://bbs.archlinux.org/viewtopic.php?pid=1445611#p1445611).
Eine mit Firefox nicht funktionierende “.asoundrc”
Meine ursprüngliche “~/.asoundrc” für diesen Fall sah (etwas verkürzt) etwa so aus:
pcm.dmix51 {
type asym
playback.pcm {
type dmix
# Don't block other users
# http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
ipc_key_add_uid true
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
slave {
# 2 for stereo, 6 for surround51, 8 for surround71
channels 6
pcm {
# mplayer chooses S32_LE, but others usually S16_LE
#format S24_LE
format S16_LE
# 44100 or 48000
# 44100 for music, 48000 is compatible with most h/w
rate 44100
#rate 48000
type hw
card 0
device 0
subdevice 0
}
#period_size 512
period_size 1024
#period_size 512
# 4096 might make sound crackle
# mplayer2 chooses 8192. Half-Life 2 chooses 16384.
# If too large, use CONFIG_SND_HDA_PREALLOC_SIZE=2048
buffer_size 16384
}
}
capture.pcm "hw:0"
}
ctl.dmix51 {
type hw
card 0
}
pcm.upmix {
type plug
slave.pcm "dmix51"
#front
ttable.0.0 1
ttable.1.1 1
#side / rear -left
ttable.0.2 1.0
#side / rear - right
ttable.1.3 1.0
#center
ttable.0.4 0.5
ttable.1.4 0.5
# bass
ttable.0.5 0.2
ttable.1.5 0.2
}
pcm.!default {
type softvol
slave.pcm "upmix"
control {
name "SW master"
card 0
}
}
Diese Datei mit ihren verketteten Upmixing-Definitionen (Stereo zu 5.1) und dem initial definierten Softvol-Regler funktioniert für praktisch alles – nur nicht für Firefox!
Den Softvol-Regler hatte ich, wie gesagt, am Anfang der Plugin-Kette angelegt, um den Input für die verschiedenen Kanäle der D2X an einer zentralen Stelle steuern zu können – bei gleichzeitiger
Aufrechterhaltung der relativen Lautstärke-Verhältnisse zwischen den Kanälen. Unter KMIX sieht das dann so aus:
Den “SW-Master”-Regler kann man dann zum Hauptkanal für die Kmix-Einstellungen machen und damit die Lautstärke über einen (!) Regler auch im Systemabschnitt der KDE-Kontrolleiste anpassen, ohne die relativen Kanal-Lautstärken zu verändern.
Lösungsansatz für das Firefox-Problem
Nach etwas Rumprobieren kam ich schließlich auf den Gedanken, dass Firefox beim Default-Device – also am Anfang der Plugin-Kette für die Sound-Verarbeitung – möglicherweise ein PCM-Device vom Typ “plug” erwartet und mit dem “softvol”-Plugin nicht umgehen kann. Ich habe daher folgende Änderung vorgenommen:
defaults.pcm.card 0
defaults.pcm.device 0
defaults.ctl.card 0
pcm.dmix51 {
type asym
playback.pcm {
type dmix
# Don't block other users
ipc_key_add_uid true
ipc_key 5678293
ipc_perm 0660
ipc_gid audio
slave {
# 2 for stereo, 6 for surround51, 8 for surround71
channels 6
pcm {
#format S32_LE
format S16_LE
# 44100 or 48000
# 44100 for music, 48000 is compatible with most h/w
rate 44100
#rate 48000
type hw
card 0
device 0
subdevice 0
}
#period_size 512
period_size 1024
#period_size 512
buffer_size 16384
}
}
capture.pcm "hw:0"
}
ctl.dmix51 {
type hw
card 0
}
pcm.upmix {
type plug
slave.pcm "dmix51"
#front
ttable.0.0 1
ttable.1.1 1
#side / rear -left
ttable.0.2 1.0
#side / rear - right
ttable.1.3 1.0
#center
ttable.0.4 0.5
ttable.1.4 0.5
# bass
ttable.0.5 0.2
ttable.1.5 0.2
}
pcm.vol {
type softvol
slave.pcm "upmix"
control {
name "SW master"
card 0
}
}
pcm.!default {
# !!!
type plug
slave.pcm "vol"
}
(Die ersten Statements dienten nur der Sicherheit, dass in jedem Fall die erste Soundkarte genutzt wird. Mit der D2X funktioniert übrigens auch die Format-Festlegung “format S32_LE”).
Und siehe da:
Die vorgenommene kleine Änderung unter dem “pcm.!default”-Eintrag und das Verlagern des Volume-Reglers in ein eigenes Plugin “vol” brachte den Erfolg! Nach einem Ausloggen aus KDE und erneutem Einloggen produzierten Youtube-Videos unter FF plötzlich Töne – ohne dass ich irgendetwas an der vorherigen Funktionalität für die D2X verloren hätte.
Im Grunde ist durch das künstliche PCM-Device vom Typ “plug” mit dem Verweis auf das slave.pcm “vol” der SW-Volume-Regler nur als ein weiteres separates Glied der PCM-Plugin-Kette definiert worden.
Warum FF im Gegensatz zu anderen Browsern und Soundquellen so sensibel auf unterschiedliche Alsa-Plugin-Typen reagiert, ist mir unklar. Aber im Moment bin ich froh, das Problem wenigstens einer Lösung zugeführt zu haben, ohne Pulseaudio anwerfen zu müssen.
Viel Spass weiterhin mit der Xonar D2X – ohne Pulseaudio !
Hi, habe Ihre Artikel zu ALSA mit großem Interesse gelesen, da ich selbst mit einem reinen ALSA-System eine multiroom-Lösung realisiert habe (Wohnzimmer 5.1, Rest Stereo) und an einigen Ecken noch Probleme habe.
Kennen Sie eine Möglichkeit, eine alsarec zu debuggen, d.h. die Plug-Kette im Einsatz zu analysieren um festzustellen wo es hakt?
Ich würde gerne auch verstehen, wie die Standard- ALSA aussieht, aber die /usr/share/alsa/alsa.conf ist je nur ein “Rahmenwerk” das sich ALSA zu Laufzeit selbst zusammensetzt. Kann man irgendwo die jeweiligen Alsa-Standard-Ketten für die generierten Devices anschaun? Hintergrund: Einige funktionieren so wie ich es für meine speziellen alsarec auch will aber ich sehe nicht, wie sie aufgebaut sind.
Was ich bisher werde realisiert noch verstanden habe, ist die Einbundung/Abwandlung von eigenen mixer-GUI (Ihr softvol).
Die angegebenen links habe ich alle schon studiert, viele Detailinfos bekommen aber der entscheidene Schritt zur eigenen Konfi gelingt mir noch nicht so wie ich ihn mir vorstelle. Beste Grüße
Hi, erstmal Danke für dein Interesse an dem Artikel. Ich bin nicht sicher, ob ich deine Frage richtig verstehe. Geht es um ein Recording-Problem oder das grundsätzliche Setup von pcm-Device-Ketten unter Alsa?
Ich kenne mich mit Recording Devices leider so gut wie gar nicht aus.
Bzgl. allg. Alsa-Wiedergabe-Setups aber Folgendes:
1) Es ist heute leider alles auf Pulseaudio zugeschnitten und Tests einzelner Alsa-Plugs sind deshalb nicht mehr ganz so einfach durchzuführen, wie das früher etwa unter KDE über das User-Interface für die Multimedia- und Phonon-Einstellungen möglich war. KDE 5 zeigt dir leider die Liste der definierten Alsa Devices für die Phonon-Einstellungen im Interface zu “systemsettings5” nicht mehr an, wenn man Pulseaudio abschaltet. Das ist mehrfach als Bug gemeldet; der wird aber wohl von den KDE-Entwicklern z.Z. nicht behandelt.
Über die Kommandozeile ist aber natürlich dennoch so Einiges an Testerei möglich. Alsa-eigene CLI-Testtools sind etwa “speaker-test” und “aplay”. Siehe hierzu die man-Seiten. Der “-D” Parameter erlaubt jeweils das Ansprechen von (selbst) definierten Alsa-Devices, die dann auf weitere Devices (als slave-Devices) einer Kette verweisen können.
2) Prinzipielles Vorgehen: Alsa-Plug- oder Device-Kette(n) definierst und testest du selber über eine eigene Alsa-Konfigurationsdatei (am besten zunächst lokal mittels einer .asoundrc-Datei in deinem home-Verzeichnis). Eine globale “/etc/asound.conf” kannst du dann immer noch aufbauen.
Du baust dabei eine Kette vom Endglied her auf. Ein typisches Endglied besteht etwa in einem (relativ komplexen) dmix-Device, das direkt die Soundkarte als “slave”-Device nutzt. Dieses Endglied testest du dann als erstes (s.u.). Anschließend kümmerst du dich um einen Signal-Einstiegspunkt (Startglied einer Kette). Das Startglied wird zunächst direkt mit dem Endglied verbunden (Zweier-Kette). Nach erfolgreichem Test schiebst du schließlich systematisch weitere Glieder in die Kette ein und testest die.
Die meisten Sound-Quellen (Browser, Player etc.) nutzen ja das (Stereo) Default-Device, um ein Signal an die Alsa-Verarbeitung abzugeben. (Das ist aber nur ein möglicher Einstiegspunkt in eine Plug-Kette.)
Du überschreibst also das Default-Device und lenkst es zunächst auf dein erfolgreich getestetes dmix-End-Device um.
Anschließend hängst du dann sukzessive weitere Glieder der Kette ein, die du dann jeweils testest.
Andere Anknüpfungspunkte/Eingangsdevices für Signale – die z.B. Video-Player für Multi-Kanal-Signale nutzen – sind etwa “surround4.0”, “surround5.1”, etc.. Für all diese potentiellen Signal-Eingangs-Devices solltest du passende Ketten zu definierten Endgliedern aufbauen. Dies gilt im besonderen dann, wenn mehrere Soundkarten verbaut sind und genutzt werden sollen.
3) Ich gehe bzgl. der Output-Konfiguration und der Plugin-Kette zwischen dem Default-Device und einem (5.1-)dmix-End-Device genau einer Soundkarte konkret wie folgt vor:
a) Datei ~/.asoundrc anlegen.
b) Dort definiere ich mir zunächst ein eigenes “dmix”-Device mit der gewünschten Anzahl an Ausgangskanälen und passendem eigenen Namen, etwa “dmix51”. Dieses Device kopple ich direkt an an eine Soundkarte. S. zu den verschiedenen Konfigurationseinstellungen etwa den Abschnitt zu “dmix” unter http://www.alsa-project.org/main/index.php/Asoundrc.
Eine Beispielkonfiguration findest du (in moderner Notation) unter “/usr/share/alsa/pcm/dmix.conf” .
Siehe aber auch den Beispiel-Abschnitt in der “.asoundrc” meines Artikels (alte Notation). Weitere dmix-Beispiele findest du im Internet.
“dmix”-Device sind deshalb interessant, weil sie einen mehrfachen Zugriff verschiedener
Anwendungen auf das End-Device erlauben.
Ob die Kanäle der Soundkarte richtig angesprochen werden, kann man testen, indem man das Tool “speaker-test” (/usr/share/alsa/speaker-test) mit passenden Parametern (Kanalanzahl, Sampling Rate, …) benutzt. Wenn du “speaker-test” auf mehreren Konsolen gleichzeitig startest, kannst du auch testen, ob die Testsounds von “dmix51” parallel, also überlappend abgespielt werden – wie ja mit dmix beabsichtigt. Kommandobeispiel: speaker-test -c 6 -D dmix51 -t wav
c) Überschreiben Default-Eingangs-Device: Nach erfolgreichem Test des Endglieds der Kette überschreibst du das Default device mit einem weiteren Definitionsabschnitt “pcm.!default” in deiner “~/.asoundrc”
pcm.!default {
type plug
slave.pcm “dmix51”
}
Das “!” sorgt dafür, dass evtl. andere Umlenkungsinformationen für das default-Device ignoriert werden.
Mit dem slave-Statement lenkst du das Default-Device direkt auf dein End-Plug “dmix51” um. Danach testest du dein Default-Device mittels “speaker-test”. Achtung: Das Default Device ist als Stereo-Device ausgelegt. Also werden über die Kette “default => dmix51” zunächst nur 2 Kanäle angesprochen, wenn du “speaker-test -c 6 -D default -t wav” als Befehl absetzt – selbst wenn dein “dmix51” prinzipiell 6 Kanäle kann.
3) Weitere Kettenglieder – z.B. ein Upmix-Device: Nun fügst du ein weiteres Plug in die Kette ein – z.B. ein pcm Upmixing Device. Siehe hierzu das Beispiel “pcm.upmix {}” im Artikel. Das “slave”-Statement des default-Eintrags passt du entsprechend an, z.B.:
slave.pcm “upmix”
Das neue Device erhält dagegen ein eigenes “slave”-Statement, das auf das nächste Glied der Kette (etwa dmix51) verweist. Dann testest du die neue Kette mit insgesamt 3 Gliedern: “default => upmix => dmix51”. Mittels des “-D”-Parameters für “speaker-test” kannst du aber auch jedes Glied deiner Kette ansprechen sozusagen als Einstiegspunkt des Tests gezielt ansprechen. Z.B.:
“speaker-test -c 2 -D upmix -t wav”
Obwohl nur 2 Kanäle über “-c 2” angegeben wurde, sollte das Upmixing nun für eine Ausgabe des Stereo-Signals auf allen 6 kanälen sorgen.
4) Nun erweiterst du die Kette um weitere von dir gewünschte Glieder. Die “slave”-Statements sind entsprechend anzupassen.
5) Ein weiteres Testtool mit ähnlichen Parametern wie “sepaker-test” ist “aplay”.
6) Softvol-Device: Nun noch ein paar Hinweise zu meinem “vol”-Device:
Das “softvol”-ist eine spezielles Device zur Lautstärke-Regelung eines Stereo-Eingangs-Signals. Ich möchte den Pegel aller Eingangssignale, die aus Musik-Playern wie Clementine oder Amarok an das “default-Device” gelangen, unabhängig von den 8 Kanal-Reglern für die Soundkarte (in meinem Fall eine D2X) beeinflussen können. Grund, wie im Artikel erläutert:
Die Lautstärke-Regelung soll das per KDE’s kmix einmal eingestellte Lautstärke-Verhältnis der Soundkartenkanäle nicht verändern.
Deshalb folgt das als “vol”-Device bezeichnete Plug direkt auf das default-Device => siehe die slave-Statements in der .asoundrc-Beispieldatei des Artikels. Als Resultat erscheinen zugehörige Regler dann zusätzlich unter kmix. Die definiere ich dann auch als Standardregler für kmix im Systemabschnitt der KDE-Kontrollleiste.
Das waren zwar alles nur Basisc in meinen Worten. Wie gesagt, ich bin nicht sicher, ob das das ist, was du für deine Probleme brauchst. Hoffe aber, es hilft ein wenig weiter.