alsa konfiguieren

[ralli]

Ich bin nach einer Zeit des Experimentierens wieder zu einer Debian Jessie Minimalinstallation zurück gekehrt. Als Fenstermanager setze ich jwm ein, als Klangregler für Sound volumeicon. Pulsaudio ist nicht im Einsatz. Ich habe alsa-base und alsa-utils installiert. Nun möchte ich nicht den auf dem Motherbord verbauten Soundchip Realtec ALC880 verwenden, weil die Soundqualität doch zu wünschen übrig läßt. Deshalb habe ich mir einen USB Stick als Soundblaster gekauft. Der wird aber offensichtlich nicht erkannt, jedenfalls taucht beim alsamixer mit F6 nur HDA Intel und USB Device auf. Wenn ich das auf USB Device umstelle, ist die Einstellung beim nächsten Aufruf von alsamixer wieder verloren, also nicht dauerhaft gespeichert. Ich möcht gerne den USB Stick verwenden, weil er eine annehmbare Soundqualität liefert. Wie bekomme ich das hin? Bisher kommt kein Ton.

[schwedenmann]

Hallo

Die alsamixereinstellungen werden normalerweise mit

alsactl store


gespeichert.

mfg
schwedenmann

[smutbert]

Ich denke hier liegt ein anderes Mißverständnis vor:
alsamixer dient nur zum Regeln der Lautstärke. Mit F6 wählst du also nur die Soundkarte aus, deren Regler du bedienen willst - darauf über welche Soundkarte die Wiedergabe standardmäßig läuft nimmt das nicht den geringsten Einfluss.

Darüber hinaus wage ich einmal vorsichtig zu bezweifeln, dass der Onboardsound gegenüber einer Soundkarte in der Qualität hörbar schlechter ist. Die überwiegende Mehrheit der Onboardsounds gibt analoge Signale mit einwandfreier Qualität aus.
Um nur als Detail beispielhaft einen einzelnen Wert der technischen Daten herauszupicken und zwar den Signal-Rausch-Abstand: Die Audio-CD bietet hier ein theoretisches Maximum von 96 dB, bei der Soundblaster Play!, die offensichtlich ebenfalls maximal 16 Bit Sampletiefe unterstützt wird der Wert vom Hersteller mit 90 dB angegeben, während er bei deinem Onboard-Codec, dem ALC880, der 24 Bit kann mit 100 dB angegeben ist.

(Alle Werte gelten für die Wiedergabe, für die Aufnahme sind die Werte bei Soundkarten wie auch Onboardsounds meistens etwas schlechter. Und ich habe nicht aus Bosheit die Werte einer älteren Soundkarte zum Vergleich herangezogen sondern die habe ich genommen, weil das die erste USB-Stickförmige Soundkarte von Creative war, für die ich überhaupt solche Werte in den technischen Daten gefunden habe.)


So viel einmal zur Klarstellung... und nun zum eigentlichen Problem:

Mit Zeilen wie

Code: Alles auswählen

defaults.pcm.!card XXX
defaults.ctl.!card XXX

in der ~/.asoundrc oder /etc/asound.conf, je nachdem ob es nur für den Benutzer oder systemweit gelten soll, kannst du die Default-Soundkarte einstellen, wobei du XXX durch Nummer oder besser noch Name der Soundkarte ersetzten musst. Wenn du dir nicht sicher bist poste einfach die Ausgabe von

Code: Alles auswählen

$ aplay -l

das mehr oder weniger bei Musik so gut wie zwangsläufige Resampeln in Alsa kann die Qualität beeinträchtigen:
Standardmäßig werden die Ausgaben mehrerer Anwendungen mit 48 kHz Samplerate gemixt, aber Musik liegt oft mit 44100 Hz (wie auf der Audio-CD) oder auch ganzzahligen Vielfachen davon vor und da kann die Qualität durchaus wahrnehmbar leiden, wenn mit dem einfachstmöglichen Algorithmus resampelt wird und bei Alsa war das zumindest früher so, möglicherweise ist es immer noch der Fall.
(Das Problem ist ja eigentlich verschwunden als sich Pulseaudio durchgesetzt hat, das noch dazu je nach Anforderungen, zwischen zwei Sampleraten, per default 48 kHz und 44100 Hz automatisch umschalten kann.)
Jedenfalls sorgt man mit einer weiteren Zeile dafür, dass mit einem ordentlichen Algorithmus geresampelt wird:

Code: Alles auswählen

defaults.pcm.rate_converter "speexrate_best"

Mit einer etwas ausführlicheren ~/.asoundrc oder /etc/asound.conf könnte man auch eine andere Samplerate für das Mixing festlegen oder die Anwendungen alternativ direkt ohne Mixing oder Resampling über die Soundkarte ausgeben lassen - dann kann aber nur mehr eine Anwendung gleichzeitig Töne von sich geben.

[whiizy]

das mehr oder weniger bei Musik so gut wie zwangsläufige Resampeln in Alsa kann die Qualität beeinträchtigen:
Standardmäßig werden die Ausgaben mehrerer Anwendungen mit 48 kHz Samplerate gemixt, aber Musik liegt oft mit 44100 Hz (wie auf der Audio-CD) oder auch ganzzahligen Vielfachen davon vor und da kann die Qualität durchaus wahrnehmbar leiden, wenn mit dem einfachstmöglichen Algorithmus resampelt wird und bei Alsa war das zumindest früher so, möglicherweise ist es immer noch der Fall.

Interessanter Nebensatz von dir, smutbert. Du gehst davon aus, daß bei Verwendung einer Mixer-Applikation in den meisten Fällen ein Resampling stattfindet?? Das will ich nicht!

Ich kenne z.B. Applikationen, bei denen lässt sich im output alsa-device explizit auswählen "Direct hardware device without any conversions". Ich gehe in so einem Fall immer davon aus, daß die Audio-Ausgabe dann auch direkt mit der eingestellten Samplerate der Applikation erfolgt (und nicht nochmal ein zwangsläufiger Zwischenschritt/Resampling in einer Mixer-App erfolgt). Wenn ich hingegen ein mixer device als output wähle, würde mich ein resampling nicht ganz so überraschen (aus deinen genannten Gründen).

Jetzt, wo ich das gerade schreibe, fällt mir auf, daß bei eben jenem Direct Zugriff auch der PCM-Regler im Mixer keine Auswirkung hat. Nur der Master-Zug und der Headphone-Zug beeinflussen dann die Lautstärke und ich will jetzt mal hoffen, die wirken erst auf den Datenstrom, nachdem das Audiointerface (hier Intel HDA) die Daten unkonvertiert verarbeitet hat.

Ob man umgekehrt dann davon ausgehen kann, daß ein wirksamer PCM-Zug in einem alsamixer potentiell ein Resampling bedeuten kann? (weil dann offenbar zunächst über einen mixer geroutet wurde?)

Du hast mich ein wenig verunsichert

[pferdefreund]

Was den Onboard-Sound angeht - für normale PCs mag das stimmen, dass die Qualität heute gut ist - aber bei meinem alten IBM R52 sind es Welten im Klang zwischen Onboard und guter USB-Soundkarte - besonders wenn der analoge Wiedergabeteil (hier Grundig-Aktivboxen) nicht dem Brüllwürfelniveau entspricht. Auch die Player und Soundquellenqualität spielen hier eine Rolle. www.irishpubradio.com - Qualität super. Gleiche Songs von Youtube - eher wie früher Mittel- oder Langwelle - einfach beschi..en.

[whiizy]

bei meinem alten IBM R52 sind es Welten im Klang zwischen Onboard und guter USB-Soundkarte -

Ja, die analoge Endstufe der Soundcard kann einiges verhunzen. Finde es leider gerade nicht wieder, aber manch ein Laptop-Ausgang hat einen leichten Roll-Off im Bassbereich, um einerseits mickrige Kopfhörer nicht überzustrapazieren und andererseits selbst nicht zuviel leisten zu müssen.

[ralli]

Hallo

Die alsamixereinstellungen werden normalerweise mit

alsactl store


gespeichert.

mfg
schwedenmann

Danke, ich dachte, das passiert nach einer Änderung automatisch.

[ralli]

Danke für Eure rege Beteiligung. Ich bin die ewige Fummelei, insbesondere nach einer Minimalinstallation leid, ich habe den Gnome Desktop installiert, Soundblaster sofort oder auch erkannt, und die Soundqualität ist zumindest bei mir um einiges besser.

[smutbert]

Interessanter Nebensatz von dir, smutbert. Du gehst davon aus, daß bei Verwendung einer Mixer-Applikation in den meisten Fällen ein Resampling stattfindet?? Das will ich nicht!

Naja, es ist in den Standardeinstellungen unvermeidbar.
Man will, dass mehrere Anwendungen gleichzeitig Töne ausgeben können, aber es gibt unzählige Sampleraten und -tiefen. 48 kHz ist wohl das üblichste, aber bei der Musik ist dagegen das Format von der Audio-CD am verbreitesten, also 44,1 kHz. Daneben gibt es eben noch unzählige weitere mehr oder weniger übliche Sampleraten, angefangen von 32 kHz oder sogar noch weniger bis hinauf zu 176,4, 192 oder gar 384 kHz. Per Software gemischt können diese Audiodatenströme erst werden nachdem sie auf ein einheitliches Format gebracht worden sind. Was die Sampletiefe angeht ist das trivial - man lässt einfach die niederwertigsten überzähligen Bits weg oder ergänzt fehlende Bits mit 0, aber die Umrechnung der Samplerate ist nicht ganz so einfach und geht gerade bei krummen Verhältnissen wie zwischen 44,1 und 48 mit Verlusten einher.

Alsa rechnet in den Standardeinstellungen alles auf 48 kHz um und mischt dann die Ausgaben (das ist das dmix-Plugin von Alsa und keine Anwendung/Applikation).

Pulseaudio dagegen wählt immerhin soweit möglich automatisch zwischen zwei Sampleraten (per default 44,1 und 48 kHz) so, dass seltener mit krummen Verhältnissen umgerechnet werden muss und es interpoliert bereits von Haus aus mit einem so guten Algorithmus, dass man meiner Meinung nach keinen Gedanken daran zu verschwenden braucht. Daher denke ich, dass man mit der Installation von Gnome in dieser Hinsicht möglicherweise/vermutlich ganz automatisch von Pulseaudio profitiert.

Natürlich kann man dmix bzw. Pulseaudio auch umgehen und so jeglichen Umrechnungen aus dem Weg gehen, aber man verliert dadurch die Möglichkeit von mehreren Anwendungen gleichzeitig etwas zu hören und kann nur Audioformate abspielen (betreffend Kanalzahl, Samplerate und -tiefe), die Treiber und Audiohardware auch unterstützen.


@Pferderfreund
ich vermisse die Empfehlung einer bestimmten USB-Soundkarte deren Preis/Leistungsverhältnis nahezu ungeschlagen ist und wolltest du nicht vielleicht auch eine Alternative zu Pulseaudio vorschlagen
(und Danke für die Empfehlung eines gewissen Internetradiosenders, der sich nun in einer Playlist von mir wiederfindet )

[whiizy]

Man will, dass mehrere Anwendungen gleichzeitig Töne ausgeben können,

Das will "Man" aber nicht immer. Es gibt auch Einzelanwendungen, die wollen exclusiven und optimalen Zugriff auf die Audiohardware haben. Diesem spezifischeren Fall sollte immer Vorrang vor einem "kleinsten gemeinsamen Nenner" gegeben werden können. Selbst wenn Multimedia heutzutage wohl eher als Standard gelten dürfte.

Im letzten Satz deutest Du es dann noch an, daß man "jeglichen [automatischen] Umrechnungen" auch noch aus dem Weg gehen könne. Zum Glück, würde ich sagen . Nach deinen letzten Beiträgen werde ich sicherlich etwas mehr darauf achten, ob das alsa-plugin dmix in Einzelfällen im Spiel ist oder nicht. Wobei natürlich gleich die Frage auftaucht: Wie weiß man eigentlich sicher, daß dieser Software-Mixer im Audiostream werkelt oder nicht? - Die bloße Anwesenheit eines Desktop-Mixers (kmix und Konsorten) lässt einem ja offenbar weiterhin die Möglichkeit, an dmix vorbei direkt auf die Audiohardware zuzugreifen (siehe mein Beispiel "Direct hardware device without any conversions"). Oder irre ich mich da?

Gruß

[ralli]

So ich habe mir das trotz der Gnome Installation noch mal angeschaut.

aplay -l ergibt:

Karte 0: Intel [HDA Intel], Gerät 0: ALC880 Analog [ALC880 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: U0x41e0x30d3 [USB Device 0x41e:0x30d3], Gerät 0: USB Audio [USB Audio]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0

eine ~/.asoundrc im Home Verzeichnis oder /etc/asound.conf gibt es bei mir überhaupt nicht. Muß ich die selbst anlegen? Und was muß ich explizit eintragen, Karte1 soll als Standard angesprochen und konfiguriert werden.

[smutbert]

@whiizy
Eine ausführlichere Antwort folgt, wenn wir rallis Problem gelöst haben.

@ralli
Mit Gnome hast du vermutlich Pulseaudio installiert und dann brauchst du dir um Alsa keine Gedanken mehr zu machen. Entweder in den Gnome-Einstellungen unter Audio oder - was mir lieber ist - mit pavucontrol Pulseaudio konfigurieren.
Im Falle von pavucontrol zuerst für die gewünschte Soundkarte unter "Konfiguration" das passende Profil wählen, zB Analog Stereo duplex und dann unter "Ausgabegeräte" diese Soundkarte "als Ausweichoption setzen", damit sie zukünftig der default ist.

Hasst du pulseaudio dagegen nicht installiert würde ich wahlweise /etc/asound.conf oder ~/.asoundrc anlegen (es ist normal, dass die noch nicht vorhanden sind) und es mit diesen Zeilen versuchen

Code: Alles auswählen

defaults.pcm.rate_converter "speexrate_best"

defaults.pcm.!card U0x41e0x30d3
defaults.ctl.!card U0x41e0x30d3

[ralli]

Danke @smutbert, das kommt in meine Unterlagen, falls es mich noch mal überkommt, eine Minimalinstallation mit alsa zu probieren. Ja und zur Zeit ist Gnome installiert und da läuft ja pulseaudio und ich hatte unter Einstellungen - Audio die Möglichkeit, die gewünsche Soundkarte für den Sound auszugeben.

[smutbert]

Sehr gut, also zur Antwort @whiizy


Als erstes darf man nicht vergessen, dass Alsa der Name für vieles ist:
- die Treiber und die Infrastruktur im Kernel und seinen Modulen
- eine Software-Schnittstelle für Anwendungen zur Audiowiedergabe
- Plug-Ins zum Routen und Verändern der Audiodatenströme
- Startskripte zum Speichern und Laden der Lautstärkeeinstellungen
- ein Haufen Kommandozeilentools wie alsamixer, aplay
- eine Bibliothek die Funktionen der gleichnamigen Software-Schnittstelle für Anwendungen zur Audiowiedergabe bereit stellt

dmix oder ganz allgemein das Mischen des Tons mehrerer Anwendungen hat mit den Mixern (Anwendungen zur Bedienung der Lautstärkeregler) nichts zu tun. Lassen wir einmal Pulseaudio aus dem Spiel. Dann dienen alsamixer, qasmixer, kmix,… nur dazu die Schalter und Regler der Soundkarte zu bedienen, die der Treiber zur Verfügung stellt.

Die Konfiguration von Alsa, die größtenteils unter /usr/share/alsa liegt, aber mit ~/.asoundrc oder /etc/asound.conf „überschrieben“werden kann, sorgt nun dafür, dass das Alsa-Plugin "plug" notwendige Konvertierungen vornimmt, so wandelt es zB Mono zu Stereo um (es gibt keine oder kaum Soundkarten, die etwas mit Monodaten anfangen können), dann durchlaufen die Ausgaben dmix zum Mischen der Audiodatenströme und werden schließlich per default an das erste Gerät der ersten Soundkarte weitergereicht (das ist nur ein grober Überblick - in der Konfiguration finden sich noch einige Besonderheiten).

Mit den Zeilen, die ich angegeben habe, wie zB

Code: Alles auswählen

defaults.pcm.!card xyz

kann man nun dafür sorgen, dass nicht einfach das erste Gerät der ersten Soundkarte das Ziel ist sondern die angegebene andere Karte.

Genauso kann man aber in der Form

Code: Alles auswählen

pcm.!default { 
	type hw
	card xyz
	device abc
}

direkt ein Gerät einer Soundkarte angeben und umgeht so alle Alsaplugins, die standardmäßig aktiv wären - mit den zuvor erwähnten Nachteilen. Unabhängig davon kann man natürlich bei allen Anwendungen eine andere Soundkarte als die default-Soundkarte für die Wiedergabe oder Aufnahme einstellen, entweder über die Einstellungen, über Kommandozeilenoptionen oder auch über Umgebungsvariablen.


Vor Jahren oder vielmehr Jahrzehnten war das alles noch ein bisschen anders. Da gab es noch Soundkarten, die mehrere Audiodatenströme gleichzeitig wiedergeben konnten. Die Soundkarte bot also beispielsweise ein Gerät mit 8 oder 16 (oder 32 oder …) Sub-Devices, von denen mehr oder weniger automatisch das erste freie angesprochen wurde. Allerdings hieß es keineswegs, dass man ohne Resampling auskam - es wurde nur oft nicht vom Audiosystem in Software gemacht sondern von der Soundkarte.

Es gibt übrigens auch noch immer genug Soundkarten, die nur 48 kHz (und ev 24 kHz und ganzzahlige Vielfache davon) als Samplerate unterstützen. Beim Abspielen von Musik _muss_ hier also Resampling stattfinden, manchmal auf einem DSP auf der Soundkarte ohne dass man es merken würde und manchmal eben in Software.
Ein prominentes Beispiel für Soundkarten, die nur die „48 kHz-Familie“ der Sampleraten unterstützen sind viele Modelle von Creative.

_____

Bei Pulseaudio ist es ähnlich wie bei Alsa
- es ist eine Hardwareabstraktionsschicht in Form eines Daemons aber auch
- eine Softwareschnittstelle für Anwendungen zur Audiowiedergabe

Pulseaudio nutzt nun also erst einmal nur die Audiotreiber von Alsa um die Hardware anzusprechen und bietet eine eigene Softwareschnittstelle zur Audiowiedergabe, die zB mittels vlc-plugin-pulse von vlc statt alsa genutzt wird. Gleichzeitig bedient Pulseaudio selbst die Regler und Schalter von Alsa. Auf die Art kommen Anwendung und Benutzer selbst gar nicht mehr mit Alsa in Kontakt.

Zusätzlich bringt Pulseaudio auch seine eigene Alsakonfiguration mit und bindet sich als eine Art virtuelle Soundkarte in Alsa ein, damit auch Anwendungen, die Alsa als Softwareschnittstelle für die Wiedergabe verwenden mit Pulseaudio funktionieren. Das ganze ist als Alsa-Plug-In implementiert und erscheint im Anwendungen wie Mixern oder anderen Audioprogrammen als Gerät namens "pulse" und wird obendrein durch die Alsa-Konfiguration von Pulseaudio zum Default gemacht.

Viele Vorteile von Pulseaudio sind offensichtlich, wie zB dass jede Anwendung ihren eigenen Lautstärkeregler bekommt, dass Pulseaudio versucht dafür zu sorgen, dass die Lautstärke erst möglichst spät heruntergeregelt wird, dass man sich die gewöhnungsbedürftige Konfiguration von Alsa erspart und auch das Mischen der Audioausgaben mit zwei alternativen Sampleraten ist eigentlich ziemlich schlau, aber es bringt halt auch einige neue potentielle Fehlerquellen und verhält sich in mancherlei Hinsicht ungewohnt.

[ralli]

Whooooow! @smutbert ich bewundere Deine Kompetenz. Deine Beiträge gehen in die Tiefe und ich habe sehr viel dabei gelernt, obwohl ich auch schon viele Jahre dabei bin.

DANKE! +1

[rendegast]

@smutbert

[whiizy]

Hallo smutbert,

schöne "Metastudie", gibt mal einen guten Überblick, wie die verschiedenen Systeme in Beziehung stehen!

Mir persönlich ging es tatsächlich nur um die Komponenten des Alsa-Universums. Ist Deine Abgrenzung von dmix gegenüber alsamixer, qasmixer, kmix, ... denn wirklich so scharf? Das Zusammenmischen verschiedener Kanalpegel macht doch in vielen Fällen nur Sinn, wenn sich generell die Audiodatenströme mischen lassen. Letzteres leistet unter alsa per default dmix, aber auch schon unter dem Vorbehalt, daß alsa vorher keine hardware-mixer im Audiointerface gefunden hat. Da kommt schon eine erste, eigendynamische Komponente ins Spiel.

Mir liegt daran, daß man die Kontrolle darüber behält, ob ein automatisches Resampling aktiv ist oder ob z.B. eine automatische Konvertierung von Mono zu Stereo erfolgt, weil das irgendwo "notwendig" erscheint.

Mal ein ganz konkretes Beispiel, wo ich mir aktuell nicht ganz sicher bin, ob da dmix nun die Finger drin hat oder nicht:

Eine virtuelle Piano-Software braucht möglichst gute Latenz / Echtzeit. Wähle ich in dieser Applikation aus ...

Code: Alles auswählen

HDA Intel PCH, ALC283 Analog; Direct hardware device without any conversions

..., dann ist die Latenz exzellent (evtl. u.a. weil dmix umgangen ist?)

Stelle ich die Ausgabe hingegen um auf ...

Code: Alles auswählen

HDA Intel PCH, ALC283 Analog; Direct sample mixing device

... ist die Latenz hörbar schleppend bzw. schlecht.

Meint alsa mit "Direct sample mixing device" nun dmix, das ja auch direct im Namen trägt? oder irgendwas anderes und es ist nur eine Ähnlichkeit?

Sollte dmix gemeint sein, dürfte dmix eigentlich keine Umkonvertierung irgendeiner Art vornehmen, da die Pianosoftware in 48 kHz arbeitet und auch die ALC283 nativ 48 kHz verarbeitet. Wo kommt die hohe Latenz dann aber her?

Hast Du dafür auch eine Erklärung?

Thanx

[smutbert]

Mit "Direct sample mixing device" ist der Weg über das dmix-Plugin gemeint und mit "Direct hardware device without any conversions" die direkte Wiedergabe über die Soundkarte - in der Alsa-Schreibweise in deinem Fall also etwas wie hw:PCH,0.

Dass mit dmix (und den meisten anderen Plug-Ins) die Latenz leidet ist auch klar, weil die einzelnen Audioausgabe erst in Häppchen gemischt werden müssen bevor sie wieder in Häppchen an die Soundkarte weitergeleitet werden. Denn dmix kann nicht einfach nur auf der faulen Haut liegen und die Daten durchwinken, nur weil das Format zufällig gerade passt und keine zweite Anwendung etwas wiedergibt - es kann ja jederzeit eine zweite Anwendung mit der Audiowiedergabe starten und dann erwartet man sich schon, dass es beim Einsetzen der zweiten Anwendung keine Unterbrechungen, Knackser oder ähnliches gibt.
Man kann aber durchaus alles konfigurieren und abhängig von der Hardware die Latenz verkleinern indem man die Daten-Häppchen (buffer_size) verkleinert, genauso wie man Samplerate und -tiefe und Zahl der Kanäle mit denen dmix arbeiten soll, festlegen kann.

Wenn es um mehrere Anwendungen und um eine möglichst niedrige Latenz geht, greift man aber meistens eher auf jack zurück. das in dieser Hinsicht wohl recht leistungsfähig und effizient ist.

[whiizy]

Danke smutbert,

ich hätte ja mit aplay -L auch mal selbst schauen können, da sind die Namen der Audio-Outputs zugeordnet.

Mir ist jetzt bei der näheren Beschäftigung mit den Outputs noch etwas Überraschendes aufgefallen. Die direkte Ausgabe auf die hw ("Direct hardware device without any conversions") hätte ich eigentlich als unverfälschter erwartet, als die Ausgabe über front ("Front speakers"). Letzteres steht nach meinem Dafürhalten für eine normale Stereoausgabe 2.0.

Nun klingt aber ausgerechnet die direkte Ausgabe über die Hardware muffiger und weniger detailliert . Dmix kann dafür ja schonmal nicht verantwortlich sein, da es in diesem Fall umgangen ist (wie Du es ja auch andeutest).

Was macht der Pfad "Front speakers" dann besser/anders als der Direktzugriff??

Zwei formale Unterschiede dieser beiden Output-Pfade sind mir schon aufgefallen. Der PCM-Zug im alsamixer (oder auch kmix) ist bei Direktzugriff nicht wirksam. Beim Abspielen über "Front speakers" hingegen verändert er die Lautstärke. Das erscheint zunächst ja auch plausibel. Aber daß zusätzlich eingeschleifte Volumenregler für den Klang förderlich sind, widerspricht eigentlich der Erfahrung (PCM-Regler stand natürlich in beiden Fällen auf gleicher Höhe max).

Hat dieser front-Kanal irgendein verstecktes Equalizing in diesen typischen Onboard-Codecs (ALC)? Oder ist der Direct-Pfad doch nicht so direkt, wie einem der Name glauben macht? Schlummert da noch irgendwo so ein Osterei, wie das dmix-plug?

Einen weiteren Unteschied finde ich auch noch im access-mode, wenn die Audio-Streams gerade fließen. RW_INTERLEAVED bei Direct hardware und MMAP_INTERLEAVED bei Front speakers. Ich habe davon bisher noch nichts gehört, daher halte ich eine negative Klangbeeinflussung erstmal für unwahrscheinlich. Ich habe die beiden Outputs hier zum Vergleich nochmal gegenübergestellt:

Code: Alles auswählen

hw:CARD=PCH,DEV=0
    HDA Intel PCH, ALC283 Analog
    Direct hardware device without any conversions

cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 64
buffer_size: 192

PCM-Zug in alsamixer und kmix funktioniert nicht.

Code: Alles auswählen

front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC283 Analog
    Front speakers

cat /proc/asound/PCH/pcm0p/sub0/hw_params

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 64
buffer_size: 192

PCM-Zug in alsamixer und kmix funktioniert.

Aber wenigstens die Latenz von front und direct ist (gefühlt) gleich, wenigstens nicht noch eine Variable im Spiel ...

Gruß

[smutbert]

Die ganze Konfiguration unter /usr/share/alsa, zB /usr/share/alsa/pcm/front.conf ist nicht ganz einfach zu durchschauen - oft ist es einfacher Dinge durch Versuch und vor allem viel Irrtum herauszufinden.

So kann man zB versuchen zwei aplay-Kommandos auf ein pcm loszulassen, um zu sehen ob ein pcm durch dmix geht:

Code: Alles auswählen

$ aplay -D front:Juli,0 -r 44100 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
$ aplay -D front:Juli,0 -r 44100 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

und auch daran, dass die 44100 beibehalten werden, was man im proc-Dateisystem überprüfen kann

Code: Alles auswählen

$ cat /proc/asound/Juli/pcm0p/sub0/hw_params 
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5512
buffer_size: 22052

sieht man, dass kein mixing und keine Konversionen stattfinden.

Für das mixing ist wie gesagt dmix verantwortlich und für das Konvertieren ein Plugin namens plug. Letzteres hat in der Standardkonfiguration, wie ich vielleicht schon erwähnt habe, lange Zeit beim Resampeln einfach nur linear interpoliert und tut es vielleicht heute noch - die klangliche Verfärbung dadurch kann durchaus hörbar, muss aber gar nicht unangenehm sein - in einem anderen Forum habe ich einmal gelesen, dass sie jemand mit dem warmen Klang eines Röhrenverstärkers verglichen hat.

Jedenfalls halte ich auch es für komplett unbedeutend in welchem Übertragungsmodus die Audiodaten übertragen werden, aber es gibt ja auch Leute, die angeblich erkennen, ob eine flac-Datei von einer Festplatte oder eine SSD abgespielt wird und ob eine CD auf einem Laptop ohne Stromnetz oder einem PC mit normalem Netzteil gerippt wurde.... und ich meine man bildet sich allzuleicht irgendwelche Unterschiede ein, selbst, wenn man gar keine erwartet bzw. der logische Verstand sogar sagt, dass es keine Unterschiede geben kann.
Dann lauert außerdem noch die Falle, dass man grundsätzlich das lautere Signal so gut wie immer als besser klingend empfindet - selbst bei ziemlich kleinen Lautstärkeunterschied.

Diese Ungewöhnlichkeit mit dem nicht immer wirksamen PCM-Regler kann ich hier nicht nachvollziehen und auch der Modus steht bei mir auf RW_INTERLEAVED egal auf welche (direkte) Art ich die Soundkarte anspreche (mittels hw:x,y oder front:x,y). Ich würde bei solchen Tests nur möglichst simple Anwendungen verwenden, zB aplay.

[whiizy]

Nettes Beispiel mit den zwei konkurrierenden Nulldatenströmen, danke smutbert!

Ich konnte auch auf diese Weise nochmal reproduzieren, was zwischenzeitlich ja schon bekannt war: Sowohl hw, als auch front, werden demnach nicht von einem dmix oder plug ausgebremst:

Code: Alles auswählen

$ aplay -D hw:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 8192

$ aplay -D hw:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

Code: Alles auswählen

 aplay -D front:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 8192

$ aplay -D front:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

Ferner sieht man, daß die default buffer- und period-sizes deutlich größer sind, als es für eine gute Latenz von Tasteninstrumenten nötig ist (Daumenregel kleiner Buffer -> geringe Latenz).

ich meine man bildet sich allzuleicht irgendwelche Unterschiede ein, selbst, wenn man gar keine erwartet bzw. der logische Verstand sogar sagt, dass es keine Unterschiede geben kann.

... in der Regel bildet man sich aber das ein, was man zuvor erwartet oder was einem persönlichen Bias entspricht. Das war in diesem Fall jetzt aber genau umgekehrt: Ich bin davon ausgegangen, daß der direkte Hardware-Zugriff am wenigsten beeinträchtigt sein müsste, und bin dann davon überrascht worden, daß der Ausgang "Front speakers" weniger verwaschen klingt.

Mal wieder weg von der Psychologie zur Technik: Ist überhaupt irgendein Grund bekannt, warum hw und front unterschiedlich klingen könnten? Drei formale Gründe hatten wir ja bisher, aber keiner davon muss auch kausal sein:

1) PCM-Fader wirksam / unwirksam
2) access: MMAP_INTERLEAVED / RW_INTERLEAVED
3) Es existieren zwei Output-Namen, hw und front. Wären sie identisch, würde einer davon ausreichen

Dir ist da auch nichts bekannt, was "Front speakers" auszeichnet, oder?

[BenutzerGa4gooPh]

@smutbert: Auch von mir danke!
Wie kann man die Abtastrate/Samplingtiefe einer vorhandenen Audio-Datei/Tonträger ermitteln?
Wie kann man bei der (evtl. ungünstigen) Wiedergabe die aktuelle Abtastrate sehen?
Wie kann man - falls notwendig - auf die Pulseaudio-Automatik Einfluss nehmen? Oder klappt das so gut wie immer?
(Hintergrund: Um die oben von dir beschriebenen Qualitätseinbußen durch unterschiedliche Raten zu vermeiden, Automatik zu prüfen.)

[whiizy]

Wie kann man die Abtastrate/Samplingtiefe einer vorhandenen Audio-Datei/Tonträger ermitteln?

Eine Möglichkeit wäre z.B. der Befehl "file" (wenn das WAV einen gewöhnlichen header hat):

Code: Alles auswählen

$ file /usr/share/sounds/alsa/Noise.wav
/usr/share/sounds/alsa/Noise.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz

Wie kann man bei der (evtl. ungünstigen) Wiedergabe die aktuelle Abtastrate sehen?

Eine Möglichkeit war oben im thread schon zu sehen. Man spielt die Audiodatei ab und schaut dann in die aktuellen Hardware-Parameter:

Code: Alles auswählen

Bsp.:
cat /proc/asound/PCH/pcm0p/sub0/hw_params

Gruß

[smutbert]

Die Samplerate und das Sampleformat zeigen auch viele Audio-/Videoplayer an, zB vlc unter Werkzeuge→Codec-Informationen und dann gibt es auch noch mediainfo und mediainfo-gui.

Und das Kommando funktioniert nur mit einer Soundkarte PCH, an deren ersten Gerät etwas ausgegeben wird. Für einen Überblick würde ich es mit

Code: Alles auswählen

$ cat /proc/asound/card?/pcm?p/*/hw_params

versuchen. Das sollte nacheinander den Status aller Geräte aller Soundkarten auflisten. Verwechslungsgefahr besteht nur, wenn gerade über mehr als ein Gerät irgendetwas wiedergegeben wird.

[…]
3) Es existieren zwei Output-Namen, hw und front. Wären sie identisch, würde einer davon ausreichen

Dir ist da auch nichts bekannt, was "Front speakers" auszeichnet, oder?

So wie es in Alsa läuft benötigt man ja irgendeine Möglichkeit die Hardware anzusprechen und das geschieht mit hw:x,y. Ohne die Möglichkeit die vorhandene Hardware zu addressieren, würde man sich mit der Definition weiterer pcms schwer tun.
Die vorhandene Alsakonfiguration definiert nun eben noch einige pcms mit aussagekräftigen Namen, wie zB iec958 für digitale Ausgänge, mit Front sind vermutlich die beiden normalen Stereokanäle gemeint, surround50, 51, 71,… für die verschiedenen Mehrkanalvarianten, hdmi für die Ausgabe über HDMI oder DisplayPort, usw.

Meine Meinung nach müsste es also im wesentlichen egal sein ob man front:x,y oder hw:x,y verwendet, nur kann man sich beim Namen front sicher sein, dass das Gerät Stereo beherrscht, genauso wie man bei surround51 weiß, dass es 6 Kanäle unterstützt.

[whiizy]

mit Front sind vermutlich die beiden normalen Stereokanäle gemeint,
[...]
Meine Meinung nach müsste es also im wesentlichen egal sein ob man front:x,y oder hw:x,y verwendet.

Zustimmung, denn so weit war ich ja selbst bereits . Aber es gibt ja wie gezeigt objektive Unterschiede bei der Verwendung, also stehen die Namen auch für Unterschiedliches.

Soweit mir bisher bekannt ist, steht "hw" für die direkte Kommunikation der Anwendung mit dem Kernel, noch genauer dem alsa Treiber im Kernel. Da "front" aber zu anderen Ergebnissen führt, könnte man daraus schließen, daß dieser Modus vorher vielleicht noch mit anderen alsa-plugins kommuniziert, bevor auch dann die Audiodaten schließlich am Kernel münden.

Ich fürchte, dazu muß man die exakten Konfigurationen unter /usr/share/alsa/ lesen und verstehen können. Das dürfte aber nur den Wenigsten vergönnt sein, vielleicht werden wir das hier nicht aufklären können.

PS: Hervorhebung von mir.