[Gelöst!] Alsa: Stereo-Kanäle tauschen?

[smutbert]

Mir fallen da nur ziemlich spezielle Fälle ein, z. B.:

Ausschließliches Nutzen von Bluetooth-Audiogeräten. Für die gibt es direkt in Alsa gar keine Treiber, sie werden aber sehr wohl über Pulseaudio- bzw. Pipewire-Module unterstützt.

Es gab mindestens ein ziemlich professionelles Audiointerface, das glaube ich über firewire angebunden wurde, für das weder OSS noch ALSA Treiber hat. Stattdessen gibt es nur einen Userspace-Treiber, der die Hardware direkt in jack zur Verfügung gestellt hat.
Damit hätte sich das ganze in Zusammenarbeit mit jack auch über das jack-Modul von pulseaudio nutzen lassen, ganz ohne Alsa. Oder auch ohne jack direkt in pipewire.

Eine weitere Möglichkeit wäre, dass man zumindest lokal gar keine Audiohardware nutzen will sondern Audioausgaben nur über das Netzwerk machen will, z.B. über DLNA an irgendein Hifi-Gerät (ich habe das zur Musikwiedergabe eine Zeit benutzt, das entsprechende pulseaudio-Modul hieß pulseaudio-dlna).

[desputin]

Alles klar, danke Euch noch mal für die ganzen Erläuterungen.

Ich versuche mal, die Quintessenz für mich zusammenzufassen:

-Alsa spielt immer direkt auf "der Hardware" ohne Resampling ab, so daß die Audio-Qualität nicht durch irgendwelche "Stufenbildungen" beim Resampling verschlechtert wird, dafür ist Alsa aber weniger komfortabel, weil nur eine Quelle auf einmal abgespielt werden kann.

-Pulseaudio resampelt immer alles und man kann niemals irgendwas "direkt auf der" Hardware abspielen, die "Stufenbildungen" finden so oder so statt.

-Pipewire spielt normalerweise "direkt auf der Hardware" ab, OHNE Stufenbildung. Nur wenn weitere Quellen als meine audiophile (Strawberry) hinzukommen, also wenn z.B. ich erstmal in Firefox was höre und dann Strawberry sich da mit einem Audio dazukommt, wird resampelt entsprechend der ersten aktiven Quelle (Firefox). Wenn der Ton in Firefox aus ist und ich stop und start beim Lied drücke in Strawberry wird - sofern Strawberry in dem Moment die einzige Auidoquelle ist, die abspielt, wieder "direkt auf der Hardware" ohne Resampling abgespielt.

Hab ich das jetzt richtig kapiert?

[thunder11]

Da du ja wohl eh alles mit 44,1 KHz vorliegen hast, ist dein Ansinnen mehr als akademisch.

Einen Qualitäts- Unterschied gibt es aus meiner Sicht bei dem bei dir anscheinend vorliegenden Material nicht. Egal, ob du PA / Pipewire / ALSA direkt nutzt.
PulseAudio resampelt natürlich auch nur dann, wenn der Default-Wert nicht der von dem Musikstück angebotenen Sampling Rate entspricht.
Pipewire macht das genauso, allerdings hast du ja das so eingestellt, dass Pipewire
bis 192 kHz nicht resampelt, wenn du solche Stücke hättest.

Mal abgesehen davon, erfahren bei bei deinem Musical Fidelity V90-DAC eh alle Dateien ein Upsampling
auf 192 KHz. Ob das nun gut ist oder nicht, will ich nicht beurteilen.
Meiner gibt von 44,1 KHZ bis 192 KHz das wieder (bzw. wandelt in analog) was aus dem Rechner kommt,
ohne einen zusätzlichen Sampling Schritt.

[Livingston]

Hab ich das jetzt richtig kapiert?

Vielleicht... oder auch nicht, denn niemandem gelingt das wirklich. Dahinter steckt eine historische Entwicklung, die unglaubliche Auswüchse hervorgebracht hat. Am ehesten erfasst man das Ganze mit diesem Bild:
https://imgs.xkcd.com/comics/standards.png

Zu Deinem vorherigen Post: Ja, so war es mal gedacht -> unten die "schmutzige" Hardware mit ihren virtuellen Devices drumrum (ganz früher verwaltet von OSS, später ALSA), darüber optional Soundserver (z.B. pulse) - am Besten gleich mit GUI und allem Drumrum.
Nach einigen Jahren schwinden die Grenzen, was dann z.B. dazu führt, dass alte Konzepte wie ALSA mit pipewire kollidieren, wesgegen pipewire Kompatibilitätsschichten aufbaut, und ganz andere Beteiligte, wie z.B. JACK überlegen, wie sie sich mit den beiden anderen "unterhalten" können, und dann folglich Module bauen, die diese Sonderfälle behandeln, während man bei den ALSA-Leuten feststellt, dass man nur dann up to date ist, wenn man all diese Besonderheiten allmählich mal berücksichtigt ... und so wird das Spiel immer weiter gehen.

Und nicht vergessen: Abgesehen von Computer-Nerds gibt es auch noch Musik-Nerds, und die bestehen auf maßgeschneiderte Lösungen. Am schlimmsten sind übrigens Leute, die gleichzeitig Computer- und Musik-Nerds sind.

[thunder11]

Nach einigen Jahren schwinden die Grenzen, was dann z.B. dazu führt, dass alte Konzepte wie ALSA mit pipewire kollidieren, wesgegen pipewire Kompatibilitätsschichten aufbaut

Verstehe ich nicht. Das wichtigste an ALSA sind die Kernel Treiber. Ohne die werden keine PCI Karten erkannt, und würde nicht der leiseste Pieps aus einem Rechner kommen.. Auch der Treiber "snd-usb-audio" stammt von ALSA. Früher gab es mal als Äquivalent OSS, was aber tot zu sein scheint.

Mir ist nicht bekannt, dass auf dieser Ebene Änderungen anstehen.

Die Frage scheint mir doch eher zu sein, wie die verschiedenen Soundserver auf die ALSA-API zugreifen,
und welche Möglichkeiten in diese implementiert sind.
Ich habe keine Ahnung von derartiger Programmierung, jedoch steckt dahinter immer eine gewisse
Logik, die kein Voodoo ist, und die ich gerne verstehen würde.

Code: Alles auswählen

journalctl -b |grep snd
Apr 15 22:12:05 XFCE kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC1220: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x1e/0x0
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:    inputs:
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
Apr 15 22:12:05 XFCE kernel: snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
Apr 15 22:12:06 XFCE kernel: usbcore: registered new interface driver snd-usb-audio

Edit:
Jack hatte ja den Nimbus, für Echtzeit Aufzeichnungen und damit für Profis der Soundserver der Wahl zu sein. Pipewire scheint diese Möglichkeiten aber langfristig ebenso zu erfüllen.

Meine Prognose ist deshalb: Jack wird es irgendwann nicht mehr geben, ebenso wie PulseAudio.
Allerdings steht das natürlich mit den "Befindlichkeiten" der Entsprechenden Entwickler entgegen,
ebenso wie das Wirrwar bei den diversen "Frameworks"
Aber das ist eben das "tolle" an Freier Software. Jeder macht sein eigenes Zeug und ist "frei"
Ob das nun das Chaos vergrößert oder nicht - ist egal.

[desputin]

Da du ja wohl eh alles mit 44,1 KHz vorliegen hast, ist dein Ansinnen mehr als akademisch.

Ich glaube, wir reden aneinander vorbei, oder? Hier ist das mit "bit-perfect" überschrieben, was ich möchte:
https://unix.stackexchange.com/question ... o-on-linux

Strawberry sieht es auch als wichtiges Feature an "Advanced audio output and device configuration for bit-perfect playback on Linux":
https://strawberrymusicplayer.org/

Wie paßt das mit Deinen Aussagen zusammen, daß mein DAC sowieso hoch-sampelt. Dann kann es ja nicht mehr bit-perfekt sein, oder wie?

[desputin]

Am schlimmsten sind übrigens Leute, die gleichzeitig Computer- und Musik-Nerds sind.

Ha ha

[thunder11]

Strawberry sieht es auch als wichtiges Feature an "Advanced audio output and device configuration for bit-perfect playback on Linux":
https://strawberrymusicplayer.org/

Das können alle Player, solange du im Player auf Alsa zurückgreifen kannst.
Aber du hast auch den Kommentar in dem von dir Verlinkten Thrread gelesen ?

¹ Bit-perfect is a strict term; it means that the audio output is identical to the input – for example, if audio output is redirected to an USB drive, then the resulting file will be identical to the original file. Audio that has been resampled, or that has passed through a mixer, is not bit-perfect.
...
1
The same fallacy as ever. If audio passes through the mixer but mixer does nothing to it - is it bit-perfect? Pulseaudio is bit-perfect when the only thing playing is an audio of the same samplerate as pulseaudio main rate. –
Barafu Albino
Apr 5, 2017 at 13:08

Und genau ist bei dir der Fall, wenn du nur Musikstücke mit 44,1 KHz hast

Wie paßt das mit Deinen Aussagen zusammen, daß mein DAC sowieso hoch-sampelt. Dann kann es ja nicht mehr bit-perfekt sein, oder wie?

Ich habe das nicht gewertet, nur darauf hingewiesen, wie es ist.
Die Frage wäre dann: Gilt das sogenannte Bit-Perfect nur bis zu Ausgang bein Rechner ?
Oder bis zum DA Wandler

[Livingston]

Nach einigen Jahren schwinden die Grenzen, was dann z.B. dazu führt, dass alte Konzepte wie ALSA mit pipewire kollidieren, wesgegen pipewire Kompatibilitätsschichten aufbaut

Verstehe ich nicht. Das wichtigste an ALSA sind die Kernel Treiber. Ohne die werden keine PCI Karten erkannt, und würde nicht der leiseste Pieps aus einem Rechner kommen.. Auch der Treiber "snd-usb-audio" stammt von ALSA. Früher gab es mal als Äquivalent OSS, was aber tot zu sein scheint.

Mir ist nicht bekannt, dass auf dieser Ebene Änderungen anstehen.

Hab ich auch nicht behauptet. Der Aufhänger meines Beitrages war das von mir verlinkte xkcd-Bildchen. Es sollte illustrieren, wie Entwicklungen im Allgemeinen unübersichtlich werden können. Soundsysteme sind da ein Paradebeispiel. Oben im Thread hat smutbert bereits klargestellt, dass JACK nicht unbedingt auf die ALSA-Pakete (user space) angewiesen ist. Die Kernelschnittstellen, die vom ALSA-Projekt eingebracht wurden, sind natürlich im Kernel stets vorhanden. Aber grapscht pipewire direkt nach der Hardware, geht es über die die snd-...-Module (sprich Kernel-ALSA), kann es auf sie verzichten und hat eigene in den Kernel eingebracht? Da wage ich keine Aussage, hab ich mir noch nicht angeschaut und lasse mich gern darüber aufklären.