[solved] PCM- und Master-Regler, wo genau im System?

[whiizy]

Neulich wurden im Thread Re: alsa konfiguieren ein paar Überlegungen zur Funktionsweise von ALSA angestellt. Mir ist allerdings noch nicht ganz klar geworden, wo die üblichen Steller PCM und Master eines Mixers genau im System zu "verorten" sind. Aufgefallen war z.B., daß bei Auswahl des ALSA-Outputs "Direct hardware device without any conversions" (im Gegensatz zu Output "Front speakers") der PCM-Steller umgangen bzw. wirkungslos ist. Erstmal nicht überraschend, denn wenn eine Anwendung die Sound-Hardware "direkt" anspricht, muss es logischerweise wohl auch indirekte Wege geben. Aber wie sieht dieser genau aus? Wird der Audiodatenstrom der Anwendung erst durch eine Mixer-Applikation geleitet, die über einen entsprechenden Steller PCM die Amplitude der Samples herunterrechnet und erst dann diesen Strom an die Soundhardware weitergibt?

Und was macht genau der Master-Regler? Entspricht er der Hardware-Schnittstelle, die üblicherweise als /dev/snd/controlC0 im System auftaucht? Ich beziehe mich hauptsächlich auch die Codecs, wie sie in Intel HDA basierten Notebooks auftauchen. Oftmals sind das Realtek ALCxxx Codecs, ein Block Diagramm konnte ich z.B. für einen Realtek ALC269 finden. Dort finde ich erst hinter dem DAC einen Block "VOL". Steht der für den Master-Regler? Ist der Master-Regler also Analogtechnik?

Vielleicht sieht da jemand etwas klarer.

Gruß

[smutbert]

Ob der Masterregler analog regelt oder digital hängt meines Wissens komplett von der Soundkarte bzw. dem Codec ab. Früher glaube ich war zumindest der Master-Regler meistens ein analoger Regler und bei einigen Modellen ist das bestimmt noch immer so, es gibt aber sicher auch Soundkarte bei denen alles digital in einem DSP passiert.
Wenn da ein Lautstärkeregler tatsächlich nach dem DAC sitzt, kann es ja nur ein analoger Regler sein, der das komplette Signal regelt, also wohl der Master-Regler.

Das mit dem PCM-Regler hat mich schon gewundert, als du es das erste Mal geschrieben hast - ich kann mir nur so etwas in der Art vorstellen, dass über "front" die Soundkarte irgendwie in einer Art 2-kanaligem Surroundmodus angesprochen wird (oder so ähnlich) und sich PCM nur für normalen Stereoton zuständig fühlt - immerhin hat man meist getrennt von PCM Regler für die diversen Surround-Ausgänge (bei mir heißen die Regler auf deutsch beispielsweise Vorne, Umgebung, Mitte und LFE).
Die normalen Lautstärkeregler bietet jedenfalls die Hardware in Verbindung mit dem Treiber an, die werden also nicht umgangen, wenn man dmix oder andere Alsaplugins umgeht.

Die Gerätedateien wie /dev/snd/controlC0 sind nach Soundkarten getrennt, die erwähnte Datei wäre also zum Beispiel das komplette „Kontroll/Lautstärkeregelgerät“ für Soundkarte Nummer 0 (hw:0) während /dev/snd/controlC1 für die zweite Soundkarte verantwortlich ist (hw:1). Dort kann man auch noch mehr Dinge machen als nur Regler und Schalter betätigen (siehe zB qashctl), aber für die meisten Anwender und Entwickler ist das uninteressant und ich habe sowieso keine Ahnung davon.
Die Gerätedateien sind sowieso eindeutig nicht dafür gedacht, dass man sich persönlich damit herumschlägt, dafür gibt es libasound2, das meines Wissens im Endeffekt so ziemlich alle Anwendungen benutzen, die über Alsa aufnehmen, wiedergeben oder die Lautstärkeregler bedienen.

[whiizy]

Ob der Masterregler analog regelt oder digital hängt meines Wissens komplett von der Soundkarte bzw. dem Codec ab.

... zumindest, ob der Master-Regler überhaupt existiert, hängt schonmal von der Soundcard ab. Ich habe nämlich gerade zum Vergleich mit dem onboard ALC283 mal eine populäre USB-Soundcard angeschlossen (Behringer UCA222). Sie hat nur einen einzigen Zug, der PCM benannt ist. Da gleichzeitig ein weiteres controller-device erscheint (/dev/snd/controlC3), wird offenbar einzig damit die Lautstärke der Behringer geregelt. Ob analog hinter der D/A-Wandlung oder vorher digital kann man ohne Schaltbild wohl kaum feststellen.

Daß sich der PCM-Regler der Behringer eher wie der Master-Regler von meinem Onboard-Codec verhält, kann man daran sehen, daß sowohl "Front speakers", als auch "Direct hardware..." in diesem Fall beide regelbar sind.

es gibt aber sicher auch Soundkarte bei denen alles digital in einem DSP passiert.

... dann gäbe es allerdings kaum einen Grund zwei Regler (Master + PCM) anzulegen, denn beide würden denselben Datenstrom beeinflussen (es sei denn, es würden im Mixer noch weitere digitale Filterstufen/EQs zwischengeschaltet sein.

Wenn da ein Lautstärkeregler tatsächlich nach dem DAC sitzt, kann es ja nur ein analoger Regler sein, der das komplette Signal regelt, also wohl der Master-Regler.

... der dann aber digital gesteuert würde, wenn unsere These von /dev/snd/controlCx stimmt. Auch kann man sich fragen, ob der ALC269 wirklich so typisch für diese große Realtek-Familie ist.

Das mit dem PCM-Regler hat mich schon gewundert, als du es das erste Mal geschrieben hast - ich kann mir nur so etwas in der Art vorstellen, dass über "front" die Soundkarte irgendwie in einer Art 2-kanaligem Surroundmodus angesprochen wird (oder so ähnlich) und sich PCM nur für normalen Stereoton zuständig fühlt - immerhin hat man meist getrennt von PCM Regler für die diversen Surround-Ausgänge (bei mir heißen die Regler auf deutsch beispielsweise Vorne, Umgebung, Mitte und LFE).

Ja, Stereo 2.0 ist im Grunde ja auch nur eine einfache Raumillusion von vielen. Aber auch hier stellt sich wieder die Frage, wo wird die Sample-Amplitude jedes Kanals verändert: In der Hardware oder bevor die Samples die Hardware erreichen?

Die normalen Lautstärkeregler bietet jedenfalls die Hardware in Verbindung mit dem Treiber an, die werden also nicht umgangen, wenn man dmix oder andere Alsaplugins umgeht.

... die surround-Kanäle kann man wohl nicht so richtig mit meinem geschilderten Fall vergleichen, denn wenn Du auf den Ausgang "Direct hardware device without any conversions" umschaltest, würdest Du ja auf Stereo zurückfallen. "Front speakers" ist aber bereits stereo und somit gut zu vergleichen.

Irgendwie sind mir da noch zu viele Unsicherheiten im Spiel ...

[smutbert]

[…]
... dann gäbe es allerdings kaum einen Grund zwei Regler (Master + PCM) anzulegen, denn beide würden denselben Datenstrom beeinflussen (es sei denn, es würden im Mixer noch weitere digitale Filterstufen/EQs zwischengeschaltet sein.

Den gibt es.
Einerseits ist es praktisch alle Lautstärken auf einmal regeln zu können (Master) andererseits möchte man unter Umständen unterschiedliche Audioquellen getrennt regeln, schließlich kann man meistens auch den
- Ton von analogen Eingängen sozusagen durch die Soundkarte durchschleifen, was dann nicht von PCM sondern von einem Regler der üblicherweise Line oder Line-In heisst geregelt wird. Zusätzlich gibt es noch weitere Klangquellen die man möglicherweise getrennt regeln will, etwa den
- Ton vom Mikrofoneingang,
- den von früher üblichen analogen oder digitalen Eingängen für CD-ROM-Laufwerke (man vergisst manchmal, dass es früher üblich war über die IDE-Schnittstelle nur die Befehle zum Abspielen von Audio-CDs an die Laufwerke gegeben wurden und die Audiodaten keineswegs über die IDE-Schnittstelle sondern an einem getrennten analogen oder digitalen Audioausgang herausgekommen sind), weites den früher üblicheren
- Ton von hardwareunterstützter Midisynthese (Wavetable oder FM-Synthese),
- den von digitalen (S/PDIF) Eingängen, egal ob optisch oder elektrisch, usw.
für all diese Klangquellen gab und gibt es zT immer noch eigene Regler.

[…]
Ja, Stereo 2.0 ist im Grunde ja auch nur eine einfache Raumillusion von vielen. Aber auch hier stellt sich wieder die Frage, wo wird die Sample-Amplitude jedes Kanals verändert: In der Hardware oder bevor die Samples die Hardware erreichen?

Mit den Reglern, die du im alsamixer siehst (und vorausgesetzt du hast selbst keine eigenen Regler definiert, was mittels softvol-Plugin ebenfalls möglich ist) beeinflusst du das was in der Soundkarte passiert, zumindest aus Sicht der restlichen Hardware - immerhin wäre ausgerechnet Pulseaudio ein Gegenbeispiel:
Das verwendet nach Möglichkeit zwar auch die Hardwareregler, aber mit einem Master- und einem PCM-Regler kann man nun einmal das Lautstärkeverhältnis der Ausgaben mehrerer Anwendungen untereinander nicht ändern, hier gibts also ähnlich wie beim softvol-Plugin von Alsa falls notwendig eine Lautstärkeregelung per Software.

[…]
... die surround-Kanäle kann man wohl nicht so richtig mit meinem geschilderten Fall vergleichen, denn wenn Du auf den Ausgang "Direct hardware device without any conversions" umschaltest, würdest Du ja auf Stereo zurückfallen. "Front speakers" ist aber bereits stereo und somit gut zu vergleichen.

Nein, es ist eigentlich egal wie du die Hardware ansprichst.
"Direct hardware device without any conversions" oder "hw:x,y" bedeutet keineswegs, dass man nur 2 Kanäle zur Verfügung hat. Ich kann meinen Onboardsound über beide Angaben durchaus mit 6 (5.1) Kanälen „füttern“.

Der Hauptunterschied von beiden gegenüber default ist, dass man ohne plug und dmix nur die Formate nutzen kann, die Hardware/Treiber unterstützen.
Da kann es dann durchaus passieren, dass man 2.1 nicht nutzen kann, weil die Hardware/Treiber nur wahlweise 2 oder 6 Kanäle erlauben, aber nichts dazwischen oder dass mit 6 Kanälen weniger Sampleformate unterstützt werden oder es ähnliche Fallen gibt.

Nur deine Beobachtung mit dem PCM-Regler, der nicht greift, wenn man die Soundkarte über den Namen "front" anspricht konnte ich noch nicht nachvollziehen, das liegt aber vor allem daran, dass ich hauptsächlich die digitalen Ausgänge meines Onboardsounds verwende und es in dem Zusammenhang ein paar weitere Besonderheiten gibt, wie zB das Fehlen von jeglichen Lautstärkereglern bei den HDMI- und DisplayPort-Ausgängen.
Aber ich werde mir das interessehalber auch noch ansehen...

[whiizy]

Ok, die Sinnhaftigkeit eines Master-Reglers hängt natürlich schon von den genauen Gegebenheiten der Eingänge ab. Ich bezog mich auf den einfacheren Fall, wenn letztlich alle digitalen und digitalisierten Quellen im PCM-Stream zusammenlaufen (maßgeblich unter der Einwirkung vom alsa-plugin dmix). - Aber selbst das Vorhandensein eines Master-Reglers im Mixer bedeutet nicht, daß automatisch auch alle Quellen von ihm kontrolliert werden; wenn ich mir nochmal das Block Diagram auf Seite 13 des ALC269 ansehe, können LINE-, MIC und PCBEEP auch erst hinter dem, was wir bisher unwidersprochen für den Master-Regler halten (DAC->VOL), eingeschleift werden.

Mit Deiner Erwähnung von softvol-Plugin kommen wir glaube ich der Sache schon näher (was den PCM-Regler angeht). Wenn ich nach "softvol" rekursiv in /usr/share/alsa/* greppe, finde ich es praktisch nur in den spezifischen (sound)cards erwähnt. In unserem Zusammenhang in /usr/share/alsa/cards/HDA-Intel.conf. Und sieh an, dort wird vorher die Definition von "front" includet und erst am Ende hw als slave angesprochen:

Code: Alles auswählen

<confdir:pcm/front.conf>

HDA-Intel.pcm.front.0 {
        @args [ CARD ]
        @args.CARD {
                type string
        }
        type asym
        playback.pcm {
                type softvol
                slave.pcm {
                        type hw
                        card $CARD
                        subdevice 0
                }
                control {
                        name "PCM Playback Volume"
                        card $CARD
                }
        }
        capture.pcm {
                type hw
                card $CARD
        }
}

Ich denke, das ist der virtuelle "Ort" des PCM-Reglers in den Systemeinstellungen. Indirekt dürfte das erklären, warum der PCM-Regler nur bei front verwendbar ist und nicht bei direkt hw (einfach weil softvol für hw nicht definiert ist). Aber was macht nun "softvol" wieder genau, und wo? Wird da nun in Software im Betriebssystem das Volumen der Samples verändert oder ist softvol nur eine Software-Schnittstelle für einen Reglerelement, welches dann den PCM-Stream innerhalb des Soundcard lautstärkemäßig manipuliert?

Ich kann meinen Onboardsound über beide Angaben durchaus mit 6 (5.1) Kanälen „füttern“.

Ah, interessant, das wußte ich noch nicht (beschäftige mich auch nicht mit surround). Ich konnte in meiner Applikation die ganzen Surround-Geschichten nur alternativ zu front oder hw auswählen. Man kann also die hw auch direkt mit "vorgekauten Mahlzeiten füttern".

Innerhalb des Topics bleibt jetzt fast nur noch die Bedeutung von "softvol" offen, wenn ich das richtig sehe ...

Dank auch an dieser Stelle schon für die Diskussion!

Gruß

[smutbert]

[…]Ich bezog mich auf den einfacheren Fall, wenn letztlich alle digitalen und digitalisierten Quellen im PCM-Stream zusammenlaufen (maßgeblich unter der Einwirkung vom alsa-plugin dmix).

Das ist aber nicht notwendigerweise so. Die hardwareunterstützte FM- oder Wavetable-Synthese erzeugt zB ein digitales Signal, das übicherweise einen eigenen Regler hatte (Midi, Wavetable oder so ähnlich) - das ist nur etwas aus der Mode gekommen, seitdem die CPUs so stark sind, dass man das alles komplett in Software erledigen kann.
Auch die erwähnten digitalen Audio-CD-Eingänge oder einfach nur beliebige andere optische oder elektrische S/PDIF-Eingänge (im Mixer meist mit IEC958 bezeichnet, aber meist ohne zugehörigen Lautstärkeregler) sind Beispiele für digitale Signale, die so direkt nichts mit dem PCM-Regler zu tun haben.

[…]Aber selbst das Vorhandensein eines Master-Reglers im Mixer bedeutet nicht, daß automatisch auch alle Quellen von ihm kontrolliert werden […]
LINE-, MIC und PCBEEP[…]

Das stimmt - habe es gerade mit meinem Onboardsound ausprobiert. Ich glaube das war bei älteren Soundkarten (meistens?) anders.
Zumindest aber dient Master immer noch als Regler für alle Kanäle, wenn man so etwas wie 5.1 nutzt...

[…]
Innerhalb des Topics bleibt jetzt fast nur noch die Bedeutung von "softvol" offen, wenn ich das richtig sehe ...

softvol ist nur ein weiteres Alsaplugin.
Man kann damit Lautstärkeregler definieren, die dann bei einer beliebigen Soundkarte angezeigt werden. So könnte man zB, wenn man Pulseaudio nicht nutzt, die Tatsache augleichen, dass HDMI-Ausgänge normalerweise über keinen eigenen Lautstärkeregler verfügen und die Audiosignale zuerst durch das softvol-Plugin schicken.
Ich habe im Forum auch schon jemand geholfen eine Konfiguration zu erstellen, bei der mit mehreren softvol-Definitionen die Signale von unterschiedlichen Anwendungen getrennt geregelt werden konnten. Rückblickend war es ein bisschen eine Schnapsidee das ganze nur mit Alsa zu machen, aber zu Beginn war mir nicht klar welche Ausmaße das annehmen würde und hinterher ist man immer klüger…

Dass softvol-Regler abhängig von der Hardware bereits in der Standardkonfiguration vorkommen war mir komplett neu - ich habe das alles für Regler der Hardware gehalten, aber stimmt das erklärt das Verhalten des PCM-Reglers und es erklärt auch wieso der PCM-Regler dann keinen Stummschalter hat, der fehlt softvol-Reglern nämlich grundsätzlich.

[whiizy]

Dass softvol-Regler abhängig von der Hardware bereits in der Standardkonfiguration vorkommen war mir komplett neu - ich habe das alles für Regler der Hardware gehalten, aber stimmt das erklärt das Verhalten des PCM-Reglers und es erklärt auch wieso der PCM-Regler dann keinen Stummschalter hat, der fehlt softvol-Reglern nämlich grundsätzlich.

Das mit dem Stummschalter (mute) ist interessant, war mir noch nicht aufgefallen, weil KMix (unter KDE) unter dem PCM-Zug einen wirksamen Stummschalter hat! Wenn man sich dann aber zum Vergleich den alsamixer ansieht, fehlt unter PCM tatsächlich der Mute-Schalter. Wenn man den Zug im alsamixer ganz herunterzieht, wird eine Pegelreduzierung von -51 dB angezeigt. Das ist genau der Wert, der im softvol-Plugin definiert ist:

Code: Alles auswählen

        [min_dB REAL]           # minimal dB value (default: -51.0)
        [max_dB REAL]           # maximal dB value (default:   0.0)

Der vermeintliche "Stummschalter" im KMix macht auch nur genau dies, er reduziert den Pegel ebenfalls nur um -51 dB (indem er den Regler nach unten zieht).

Die Umgehung des Master-Reglers habe ich gerade stichprobenartig auch einmal getestet (ALC283). Das eingebaute Laptop-Mikrofon läßt sich über den Regler "Mic" (auch verstärkt mit "Mic Boost") einblenden und über Kopfhörer ausgeben (der Master beeinflusst diesen Pegel nicht). Ein Grund mehr wie gewohnt alle Eingänge abzuschalten, die man nicht unbedingt braucht, da sonst Dreck am Master-Regler vorbei eingekoppelt werden kann.

softvol ist nur ein weiteres Alsaplugin.

... dann interpretiere ich das jetzt einfach mal so, daß der Datenstrom der Quellapplikation vom "ALSA-System" entgegengenommen wird und irgendwo außerhalb des Audiointerfaces im Pegel verändert wird. Also ganz klassisch von CPU, RAM und irgendwelchen alsa-libs verarbeitet wird. Das letzte plugin in der Kette dürfte dann wohl immer "hw" sein, welches die Audiodaten schließlich an den Kernel gibt, welcher seinerseits dann die Audiodaten an den Ringbuffer in der Soundcard-Hardware übergibt.

Könnte man das vereinfacht so sagen?

[smutbert]

Ja genau

[whiizy]

Ja genau

... eigentlich ein schönes Schlusswort

Wenn, ja wenn da nicht noch diese kleine blöde Anomalie im Raum stünde
Wenn die letzten beiden Stationen immer das Alsa-plugin hw und der kernel vor der Füllung des Ringbuffers in der Soundcard sind, wie schaffen es dann vorgelagerte plugins in der Kette, die Speicherorganisation des Ringbuffers fundamental zu ändern? Und warum überhaupt? Kann doch dem letzten Plugin überlassen bleiben?

Ich meine folgendes: Gibt man über den Alsa-Output "front" aus, was u.a. das Durchlaufen des plugins softvol impliziert, wie wir gesehen haben, dann werden die Daten über eine memorymap mit der Hardware ausgetauscht. Wird als Alsa-Output hingegen "hw" ausgewählt, geschieht dies über standard read / write transfers. Diese beiden Wechselfälle kann ich hier belegen:

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

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

Soweit ich hier verstanden habe, ist MMAP eigentlich das vorteilhaftere Verfahren. Aber was versprechen sich vorgelagerte Plugins davon (eines davon könnte z.B. ja softvol sein), den Ringbuffer ganz am Ende der plugin-Kette zu beeinflussen?

Reproduzieren kann ich das auf zwei unterschiedlichen Notebooks, eines davon mit Jessie, das andere mit Sid.

[smutbert]

Auf welche Art und Weise die Daten an ihr Ziel kommen hat mich bei Alsa bis jetzt noch nie besonders interessiert - Hauptsache sie kommen an ☺.

Aber egal, hast du es mit aplay getestet?
Das verwendet laut Manpage standardmäßig "read/write I/O mode" (RW_INTERLEAVED) und man kann über den Schalter -M den "memory-mapped (mmap) I/O mode" aktivieren. Ohne diesen Schalter kann es mit Plugins zB so aussehen, dass aplay die Plugins in ersterem Modus beliefert, aber das Plugin dann die Hardware mittels mmap versorgt:

Code: Alles auswählen

$ aplay -vvv -D plughw:1 /usr/share/sounds/alsa/Front_Left.wav 
Wiedergabe: WAVE '/usr/share/sounds/alsa/Front_Left.wav' : Signed 16 bit Little Endian, Rate: 48000 Hz, mono
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
Slave: Hardware PCM card 1 'HDA Intel PCH' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 16384
  period_size  : 4096
  period_time  : 85333
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 4096
  period_event : 0
  start_threshold  : 16384
  stop_threshold   : 16384
  silence_threshold: 0
  silence_size : 0
  boundary     : 4611686018427387904
  appl_ptr     : 0
  hw_ptr       : 0

Ohne Plugin kommen dann die Audiodaten nur mittels mmap zur Soundkarte, wenn man das explizit mit dem Schalter -M / --mmap verlangt.
Für andere Anwendungen mag ähnliches gelten und vielleicht verhalten sich Anwendungen sogar gezielt anders, wenn sie erkennen, dass (keine) zusätzlichen Alsaplugins zwischen ihnen und hw:x,y agieren?

[whiizy]

Aber egal, hast du es mit aplay getestet?
Das verwendet laut Manpage standardmäßig "read/write I/O mode" (RW_INTERLEAVED) und man kann über den Schalter -M den "memory-mapped (mmap) I/O mode" aktivieren.

Jep, war hier schonmal zu sehen: Front endete bei MMAP und hw bei RW. Aber ich erwarte selbstverständlich nicht, daß man das alles behalten kann.

Daß man MMAP mit -M bei aplay gezielt einschalten kann, eröffnet vielleicht eine interessante Möglichkeit! Eventuell lässt sich dann MMAP auch über eine .asoundrc permanent setzen, so daß nicht mehr RW die Voreinstellung bei direkter hw Ansprache wäre. Dann könnte ich vergleichen, ob damit auch der gehörte Unterschied zwischen front und hw bei mir verschwindet (weil dann beide am Ende über MMAP ausgeben). [Zur Erinnerung; das war ja der skurrile Befund]

Leider erkenne ich da aber im Plugin hw keine Möglichkeit, den Transfer RW mit MMAP zu überschreiben . Siehe diese Beschreibung bei alsa-project.org:

Code: Alles auswählen

Plugin: hw

This plugin communicates directly with the ALSA kernel driver. It is a raw communication without any conversions. The emulation of mmap access can be optionally enabled, but expect worse latency in the case.

The nonblock option specifies whether the device is opened in a non-blocking manner. Note that the blocking behavior for read/write access won't be changed by this option. This influences only on the blocking behavior at opening the device. If you would like to keep the compatibility with the older ALSA stuff, turn this option off.
pcm.name {
        type hw                 # Kernel PCM
        card INT/STR            # Card name (string) or number (integer)
        [device INT]            # Device number (default 0)
        [subdevice INT]         # Subdevice number (default -1: first available)
        [sync_ptr_ioctl BOOL]   # Use SYNC_PTR ioctl rather than the direct mmap access for control structures
        [nonblock BOOL]         # Force non-blocking open mode
        [format STR]            # Restrict only to the given format
        [channels INT]          # Restrict only to the given channels
        [rate INT]              # Restrict only to the given rate
        [chmap MAP]             # Override channel maps; MAP is a string array
}
Function reference

    snd_pcm_hw_open()
    _snd_pcm_hw_open()

Plugin: mmap_emul
pcm.name {
        type mmap_emul
        slave PCM
}

Noch schlimmer, diese Beschreibung verwirrt zusätzlich dadurch, daß nur eine MMAP-Emulation erwähnt wird (und daß diese natürlich die Latenz verschlechtern könne). Das wird doch nicht am Ende das sein, was "aplay -M" einschaltet?? Ich will einfach mal hoffen, daß es auch noch einen zweiten echten MMAP unter ALSA gibt und nicht nur diesen emulierten. Zumindest finde ich den "type mmap_emul" auch in keiner einzigen der alsa Kartenkonfigs unter /usr/share/alsa/cards/* verwendet.

Sieht jetzt ein bisschen verrannt aus ...

[smutbert]

mmap_emu ist glaube ich vor allem für Hardware/Treiber gedacht mit denen echtes mmap nicht geht und das vor allem in Kombination mit Anwendungen die mit mmap besser (oder überhaupt) funktionieren.

Ansonsten könnte es einen auch beruhigen, dass mit Plugins mmap gegenüber der Soundkarte auch verwendet wird, wenn es die Anwendung selbst nicht verwendet.

[whiizy]

mmap_emu ist glaube ich vor allem für Hardware/Treiber gedacht mit denen echtes mmap nicht geht und das vor allem in Kombination mit Anwendungen die mit mmap besser (oder überhaupt) funktionieren.

Ok, wenn ein Codec nur RW verarbeiten könnte, dann würde es Sinn machen, nach aussen MMAP zu emulieren und nach innen nach RW zu konvertieren. Anscheinend ist RW wohl ein älterer oder primitiverer Standard.

Nun kann (m)ein Onboard-Codec aber beides, wie wir gesehen haben. Dann müsste es doch eigentlich möglich sein, die Hardware auch direkt mit MMAP und nicht dem Standard RW ansprechen zu können. Wohlgemerkt auch ohne, daß man in speziellen Fällen unerwünschte Plugins, wie dmix oder softvol, vorschaltet. Hältst Du das für gänzlich unmöglich?

[smutbert]

Imho ist es hauptsächlich Sache der Anwendung die Daten in einem geeigneten Modus zu übertragen und am Beispiel von aplay sieht man, dass mmap möglich ist. Warum die meisten Anwendungen per default nicht mmap verwenden, weiß ich nicht (habe es mit gstreamer-Anwendungen und mit vlc getestet).

Auf den meisten Systemen wird sich ohnehin Pulseaudio darum kümmern und das verwendet offensichtlich standardmäßig mmap.

[whiizy]

Sorry, ich hatte mich zu unklar ausgedrückt. Aplay zeigte natürlich, daß MMAP möglich ist. Und ich mutmaße mal, daß sich viele andere Applikationen um MMAP überhaupt nicht scheren, und daher unweigerlich der default RW greift. Was ich meinte, war eigentlich die bewusste Änderung des defaults RW auf MMAP unabhängig von einer bestimmten Audioquelle.

Aber ich verabschiede mich erstmal von diesem Gedanken. Man könnte es wohl höchstens noch mit Tricks versuchen. Da die anderen diskutierten alsa plugins intern anscheinend beiläufig auf MMAP konvertieren, könnte man versuchen das minimalinvasivste von ihnen quasi nur für diesen Zweck vorzuschalten. Eventuell nur das softvol plugin, aber dann wäre man ja fast schon wieder beim vordefinierten front output. Eventuell kann man auch das route plugin dazu zweckentfremden, aber dazu kann ich überhaupt nichts Fundiertes sagen (nichtmal, was das genau macht, also nagel mich da jetzt bitte nicht drauf fest).

Als letztes bliebe noch das Prinzip Hoffnung oder Wünsch-Dir-was , daß nämlich die erzwungene Festlegung auf bestimmte Raten und Formate im plugin hw den Rückfall auf RW vermeidet oder eben MMAP automatisch triggert:

Code: Alles auswählen

Plugin: hw

pcm.name {
        type hw                 # Kernel PCM
        card INT/STR            # Card name (string) or number (integer)
        [device INT]            # Device number (default 0)
        [subdevice INT]         # Subdevice number (default -1: first available)
        [sync_ptr_ioctl BOOL]   # Use SYNC_PTR ioctl rather than the direct mmap access for control structures
        [nonblock BOOL]         # Force non-blocking open mode
        [format STR]            # Restrict only to the given format
        [channels INT]          # Restrict only to the given channels
        [rate INT]              # Restrict only to the given rate
        [chmap MAP]             # Override channel maps; MAP is a string array
}

Und da fällt mir auch noch eine dritte Möglichkeit wieder ein, daß jackd vorgeschaltet und optimiert vielleicht auch einen Einfluß auf MMAP haben könnte. Erfahrungsgemäß geht aber eigentlich nichts über den optimierten, direkten Zugriff auf die Soundhardware, wenn die Leistungsdaten eines Laptops eng limitiert sind und die Latenz möglichst kurz sein soll.

[whiizy]

Ich habe jetzt vielleicht doch noch einen Trick gefunden, indem ich das plugin "plug" (ja, so heißt das tatsächlich) "vorgeschaltet" habe. Dazu habe ich mir eine ~/.asoundrc angelegt und dort das plaziert:

Code: Alles auswählen

pcm.PCH {
        type plug
        slave {
                pcm "hw:0,0"
                rate 48000
        }
}
ctl.PCH { type hw; card PCH; }

pcm.!default pcm.PCH
ctl.!default ctl.PCH

Angelehnt hatte ich mich an ein Grundgerüst einer .asoundrc, die man sich mit dem script asoundrc generieren kann. Dieses rohe Muster hatte zunächst so ausgesehen:

Code: Alles auswählen

pcm.PCH { type hw; card PCH; }
ctl.PCH { type hw; card PCH; }
pcm.!default pcm.PCH
ctl.!default ctl.PCH

(PCH ist nur der Name für diesen Typus von Karte "HDA Intel PCH")

Das alsa-plugin "plug" wird normalerweise benutzt, um Formate zu konvertieren. In meinem Fall muss es das nicht tun, denn ich gehe mit 48000 Hz seitens der Applikation rein und mit der festeingestellten "rate 48000" wieder raus.

Der angestrebte Nebeneffekt: MMAP wird jetzt verwendet

Code: Alles auswählen

cat /proc/asound/card0/pcm0p/sub0/hw_params 

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

Ob meine .asoundrc so ok ist oder ob man das noch geschickter machen kann, weiß ich nicht. Ich kenne mich mit der Syntax nur sehr schlecht aus. Ich verstehe noch, daß das Ausrufezeichen die enstprechende, vorhandene Konf übersteuern soll. Ob dann aber noch irgendwelche anderen Reste der Konf default aktiv bleiben oder warum man auch noch das plugin "ctl" übersteuern solte (und was das macht), ist mir etwas schleierhaft.

Meine Quellapplikation hatte schon immer auch einen wählbaren Alsa-Output namens "Default ALSA Output". Dieser wird nun offenbar von meiner .asoundrc definiert. Wo die Applkation allerdings den Namen "Default ALSA Output" her hat, bleibt ihr Geheimnis (in aplay -L wird er zumindest nicht gelistet. Vielleicht wird er von ihr selbst vergeben).

Der PCM-Regler ist in diesem Szenario übrigens unwirksam (so soll es ja auch sein).

[smutbert]

plug konvertiert afaik nur, wenn es notwendig ist → wenn du mit einer Anwendung ein von der Soundkarte unterstütztes Format über plug aber ohne dmix abspielst, sollte nichts konvertiert werden, du könntest die Angabe der Abtastrate also auch einfach weglassen und damit auch andere Abtastraten ohne Konvertierung abspielen.

Es ist meistens eine gute Idee ein gleichnamiges Kontrollgerät ctl.xxx zu definieren, das zur gleichen Hardware führt wie das pcm.xxx. Das dient zwar in erste Linie dazu die Lautstärkeregler zu bedienen, aber es gibt auch noch andere Steuerfunktionen und einige Anwendungen verweigern den Dienst, wenn sie kein passendes Kontrollgerät finden. Ein Beispiel dafür wäre (glaube ich) jack.

Die Namen für definierten pcms und ctls kann man auch in der Konfigurationsdatei vergeben, mit einem Abschnitt hint, zB

Code: Alles auswählen

pcm.onboard {
        type hw
        card PCH
        device 1
        hint {
                show on
                description "Onboardsoundkarte (direkt)"
        }
}

In Zusammenhang mit mancher Software wie KDE/Phonon hilft da ungemein, weil Geräte ohne "beschreibende Namen" manchmal einfach ausgeblendet werden.

[whiizy]

Yep, die statische Beschränkung auf 48000 bringt vermutlich keinen Vorteil, habe ich wieder weggelassen. Sie wird sowieso nur einmal beim Open der hw ausgehandelt und ändert sich dann nicht mehr. Gegenprobe habe ich mit 44100 gemacht und funktionierte auch.

Vielen Dank für deine Ergänzungen, habe es jetzt so:

Code: Alles auswählen

pcm.PCH {
        type plug
        slave {
                pcm "hw:0,0"
        }
        hint {
                show on
                description "Onboard MMAP Transfer"
        }
}
ctl.PCH {
        type hw
        card PCH
        }

pcm.!default pcm.PCH
ctl.!default ctl.PCH

In der Applikation wähle ich allerdings weiterhin den "Default ALSA Output" und nicht den "Onboard MMAP Transfer" bezeichneten pcm.PCH.

[smutbert]

Du vergibst den Namen ja auch pcm.PCH und nicht pcm.default. Wo die Namen für default, front usw. in der Standardkonfiguration gesetzt werden weiß ich nicht, aber ich habe den vagen Verdacht, dass man die Namen ungefähr so ändern könnte - ohne es ausprobiert zu haben:

Code: Alles auswählen

pcm.default.hint.!description "meine default-Soundkarte"

[whiizy]

Wo die Namen für default, front usw. in der Standardkonfiguration gesetzt werden weiß ich nicht, aber ich habe den vagen Verdacht, dass man die Namen ungefähr so ändern könnte - ohne es ausprobiert zu haben:

Code: Alles auswählen

pcm.default.hint.!description "meine default-Soundkarte"

Die Bennennung des default Outputs scheint auch wieder so ein Sonderfall von ALSA zu sein. Mit aplay -L finde ich allenfalls einen pcm "sysdefault" und keinen pcm "default" (vermutlich stehen die irgendwie in einer Link-Beziehung):

Code: Alles auswählen

...
sysdefault:CARD=PCH
    HDA Intel PCH, ALC283 Analog
    Default Audio Device
...

Vielleicht ist das sogar der tiefere Grund, daß sich meine Quellapplikation dafür einen Namen "ausdenkt", wie erwähnt "Default ALSA Output". Ich glaube, diese Applikation jetzt auch noch overriden zu wollen, schenke ich mir einfach. Blöd ist natürlich, daß man dann nicht erkennt, daß sich hinter dieser Benennung in Wirklichkeit mein neues plug-Konstrukt (pcm.!default) verbirgt. So was kann man irgendwann mal vergessen ...

[smutbert]

Hab mir das nur schnell auf meinem System mit Pulseaudio angesehen:

Code: Alles auswählen

$ aplay -L
default
    Playback/recording through the PulseAudio sound server
…

und

Code: Alles auswählen

$ cat /usr/share/alsa/pulse-alsa.conf
# This file is referred to by /usr/share/alsa/pulse.conf to set pulseaudio as
# the default output plugin for applications using alsa when PulseAudio is
# running.

pcm.!default {
    type pulse
    hint {
        show on
        description "Playback/recording through the PulseAudio sound server"
    }
}

ctl.!default {
    type pulse
}

[whiizy]

Hab mir das nur schnell auf meinem System mit Pulseaudio angesehen:

Code: Alles auswählen

$ aplay -L
default
    Playback/recording through the PulseAudio sound server
…

... auf einem Debian Sid ist das default unter Alsa auch an Bord:
$ aplay -L

Code: Alles auswählen

...
default:CARD=PCH
    HDA Intel PCH, ALC255 Analog
    Default Audio Device
sysdefault:CARD=PCH
    HDA Intel PCH, ALC255 Analog
    Default Audio Device
...

Neben dem verwandten sysdefault, welches unter Pulsaudio auch noch weiterexistiert. Trotzdem einen Punkt an Pulseaudio, daß es an dieser Stelle etwas klarer gestaltet ist . Daß eine neue, zusätzliche Abstraktionsschicht auch mal etwas "abstrakter" aussieht, darf man glaube ich schon erwarten.

[whiizy]

Zum Abschluss noch, wofür man den ganzen Kram z.B. gebrauchen kann. Ich habe heute mal etwas unorthodox (weil ich keinen orthodoxen Weg kenne) versucht, die Latenzen der diskutierten PCM-Outputs miteinander zu vergleichen. Dazu habe ich auf der PC-Tastatur den Ton eines virtuellen Pianos angeschlagen und mit dem eingebauten Micro eines zweiten Laptops das Geräusch von Tastaturklick und abgestrahltem Piano-Klang aufgenommen. Die Zeitspanne ("Latenz") zwischen diesen beiden Events ist u.a. abhängig vom jeweiligen Alsa-Device. Vier dieser devices habe ich durchgetauscht: dmix, hw, front und mmap. Das Bild verdeutlicht, wie ich die Zeitspanne in einem Waveeditor bestimmt habe:



Wie nicht anders zu erwarten, ist die Latenz von dmix mit 53 ms im Mittel grausam (zumindest in seinen Standard-Einstellungen). Für diesen Zweck nicht zu gebrauchen. Außerdem ist sie noch schwankend, was eine persönliche Adaption verhindert.

Am besten schneidet der direkte hw Zugriff im Vergleich ab. Wenn auch nur geringfügig gegenüber "Front Speakers" und auch meinem mmap plugin, aber dennoch hatte ich diesen Eindruck schon vor dem Test (!). Dahingegen scheinen front und mmap sich praktisch nicht zu unterscheiden. Ich hätte mir wohl die Mühe sparen und mich mit front begnügen können (der ja intern auch schon mit mmap arbeitet).

Was unter dem Strich aber als seltsames Ergebnis für mich persönlich weiter Bestand hat, daß hw erstens anders und zweitens schlechter, als front und auch mmap klingt. Sollte es da tatsächlich einen ursächlichen Bezug zu den Transfer-Modes RW versus MMAP geben, dann wäre das IMHO ein ziemliches Ding. Andererseits ist es kaum vorstellbar, daß das bisher unentdeckt geblieben wäre. Also sehr unwahrscheinlich.

Danke smutbert und allen, die dran geblieben waren!