staging.inyokaproject.org

Nochmal ein paar Bilder.

Mit GStreamer bin ich mir nicht sicher. Wahrscheinlich gehört das überhaupt nicht da hinein... aber irgendwie schon doch.

Ich werde mal im Multimediaforum nachfragen und nach hierhin verlinken.

Huhu,

es ist leider etwas komplexer (oder simpler, je nachdem, wie man es betrachtet). 😀

Generell (und etwas vereinfacht) kann man das Prozedere so beschreiben:

Ein Programm spielt eine Audiodatei ab. Dabei greift es entweder auf eingebaute Routinen (und/oder eigene Bibliotheken), auf externe Bibliotheken, oder auf Gstreamer/Phonon zurück. Das Programm generiert dadurch selbst oder via Gstreamer/Phonon einen Audiostream. Dieser wird von einem Soundserver entgegen genommen (dabei kann auch ALSA direkt angesprochen werden, denn ALSA bringt einen minimalistischen Soundserver mit). Der Soundserver kann nun allerhand mit den eingehenden Audiostreams anstellen, zB kann er sie auch an andere Soundserver weiter reichen. Und schlußendlich tut er genau das: er gibt beim ALSA-Soundserver den Audiostream ab. Der ALSA-Soundserver reicht ihn dann via Module ("Treiber") mit Hilfe des Kernels an die Hardware durch.

Bei einer Aufnahme geht das Spiel nur in die umgekehrte Richtung. Ausnahme: wenn die Aufnahmequelle eine Datei ist muss sie nicht über die Hardware laufen.

Das ist das Szenario, mit dem es 99% der User zu tun haben.

hth

Hallo,

@pepre: Danke!

@kaputtnik: So, jetzt mach' da mal 'ne Grafik draus! 😀

Gruß, noisefloor

Einen hab ich noch! 😀

Wichtig, weil es die zentrale Komponente ist.

ALSA gliedert sich bei der Streamverarbeitung in drei Teile:

• den Soundserver (konfigurierbar über zB .asoundrc)

• Software, die sich steuernd (via Modul) mit der HW unterhält (zB Alsamixer)

• das Kernelmodul ("Treiber"), das den Audiostream (und die Steuerbefehle) gemäß der Spezifikation der HW aufbereitet

Der letzte Punkt erklärt, warum zB bei den HDAs soviel Kuddelmuddel herrscht, wenn sich der Soundchip nicht eindeutig identifiziert. Dann weiß das Modul schlicht nicht, welche Routen, Befehle und Formate benötigt werden, um den Soundchip korrekt anzusprechen. Das HDA-Modul fällt dann auf Grundeinstellungen zurück und hofft das Beste.

Danke pepre 👍

noisefloor schrieb:

@kaputtnik: So, jetzt mach' da mal 'ne Grafik draus! 😀

Ich werde es versuchen. Soooo, weit weg war ich ja gar nicht von der Wahrheit ☺

Zur Not schreibt man halt unter dem Bild "vereinfachte Darstellung". Alle eventualitäten kann man wohl eh nicht in einem Bild unterbringen. KOmme aber wohl erst im Laufe der nächsten Woche dazu.

kaputtnik schrieb:

Alle eventualitäten kann man wohl eh nicht in einem Bild unterbringen.

Das stimmt. Man sollte von dem Szenario ausgehen, das die Standard-Installation mit sich bringt. Denn: wenn jemand zB PulseAudio von der Platte rupft, dann wird er schon wissen, was er tut. Ich hab's mal skizziert:

http://files.pepre.de/fluss.png

Die schwarzen Pfeile bedeuten, dass dort noch Audioformat-Daten transportiert werden. Die grauen Pfleile handhaben statt dessen "rohe" PCM Audio-Streams.

Das Gestrichelte kann man auch weg lassen, da bei Ubuntu immer ein Soundserver mitinstalliert wird. Die Doppelpfeile machen an und für sich Sinn, da ja immer Meldungen (zB "Nächstes Datenpaket schicken", "Bitte", "Danke") hin und her gehen. Das muss der User aber eigentlich nicht wissen.

Aufnahme (in rot). IdF spielt ein Programm via Gstreamer die Aufnahmedaten dem Soundserver zu, und ein anderes Programm greift dies dort direkt ab, um es in ein Audioformat zu wandeln. Zweite Variante: die Quelle wird von der Soundkarte an den Soundserver durchgereicht; Rest wie vorher. Auch da wären Doppelpfeile sinnig, aber auch verwirrend.

Edit: es gibt natürlich auch noch spezielle Szenarios. ZB kann man den Soundserver dazu zwingen unter Umgehung des ALSA-Soundservers direkt mit dem Treiber zu kommunizieren (was aber nichtsdestotrotz weiterhin die HW-Steuerung via ALSA erlaubt). jack ist für sowas prädestiniert, aber auch mit PulseAudio läßt sich das machen. Aber - wie gesagt - der normalsterbliche User hat mit sowas eher selten zu tun.

Was ich nicht weiß: ob Phonon Gstreamer ersetzt, oder ob Phonon seinen Output u.U. zu Gstreamer weiter leitet. Ich tippe auf ersteres. Da muss ein KDEler ran, um das zu klären. Als Fluxboxler mit jack/ALSA habe ich keinen Bedarf dafür.

Edit2: Es gibt auch noch Soundkarten, die selbst den Soundserver darstellen. Aber da sind wir in der Größenordnung > 500€, was sich nur wenige leisten. Wer sowas kauft, weiss idR über rechnergestütztes Harddisk-Recording, Routing, Latenzen u.ä. Bescheid.

Edit3: ich habe mir den Artikel nochmal angesehen. Aus Gründen der Verständlichkeit habe ich wohl beim Schreiben einige Vereinfachungen gemacht, die nun im Widerspruch zur Grafik, die da kommen wird, stehen würden. Man müsste das weit genauer aufdröseln, um keine Verwirrnis aufkommen zu lassen. Beispiel:

Soundquelle  ->  ALSA  ->  PulseAudio  ->  ALSA-Treiber  ->  Hardware

Das müsste korrekt (für Programme, die nur ALSA sprechen) so lauten:

Soundquelle -> von PA emulierte ALSA-Schnittstelle -> PulseAudio -> (ggf. ALSA-Soundserver) -> ALSA-Treiber -> Hardware

Hm, verständlich ist was anderes. ☹

Was bedeuten würde, dass man mit dem Einfügen der Grafik, die da kommen wird, gleichzeitig den Artikel überarbeiten müsste, um Widersprüche auszumerzen. Ich weiß aber nicht, wann ich dazu komme, das könnte einige Zeit dauern; und die nächsten paar Wochen sowieso nicht. Oder man lässt es darauf ankommen und wartet auf den Shitstorm. Evtl hilft ja auch ein kleiner Hinweis, dass die die Erklärungen bewußt vereinfacht sind. Was meint ihr?

pepre schrieb:

kaputtnik schrieb: http://files.pepre.de/fluss.png

Ah, ok. Sieht doch, mit der Erklärung, schon gut aus ☺

Ich bin nur der Meinung, das man mehrere Bilder machen sollte.

Edit: es gibt natürlich auch noch spezielle Szenarios.

Kann man vernachlässigen.

Was ich nicht weiß: ob Phonon Gstreamer ersetzt, oder ob Phonon seinen Output u.U. zu Gstreamer weiter leitet.

Ich nutze KDE... Phonon nutzt GStreamer ab Precise als Backend (vorher war es xine). So wie ich http://userbase.kde.org/Phonon verstehe, ist Phonon in erster Linie eine Schnittstelle für Programmautoren und dient als Zwischenschicht um die Kommunikation zu vereinheitlichen. Es wird also immer bleiben (so es die KDE-Devs wollen). IMHO kann man das in den Bildern aussparen. Vllt schreibe ich auch ein kleinen Artikel dazu, der sich in erster Linie mit der Benutzerschnittstelle befasst.

Edit2: Aber da sind wir in der Größenordnung > 500€

Kann man vernachlässigen.

Edit3: ich habe mir den Artikel nochmal angesehen. Aus Gründen der Verständlichkeit habe ich wohl beim Schreiben einige Vereinfachungen gemacht, die nun im Widerspruch zur Grafik, die da kommen wird, stehen würden.

Oder die Grafiken ebenso vereinfachen, oder eben mehrere Grafiken machen.

Hm, verständlich ist was anderes. ☹

Ich liebe das Soundsystem unter Linux 😊 😉

Was bedeuten würde, dass man mit dem Einfügen der Grafik, die da kommen wird, gleichzeitig den Artikel überarbeiten müsste, um Widersprüche auszumerzen.

Wie gesagt, mehrere Bilderchen. Vorschlag:

1. Bild für Zusammenhang Soundchip ←> Kernel ←> Treiber (Wäre dieses Bild)

2. Bilder für Soundserver

   1. Bild für Augabestreams (zB.: Audio-/Videoplayer spielt Sound über die Boxen)

   2. Bild für Aufnahemstream (zB.: LP, Kasette oder Mikro aufnehmen/wiedergeben)

Evtl. kann man die letzten Bilder auch zusammenfassen (Wäre dieses Bild gewesen). Wobei dort noch die Legende für Pfeile fehlt: Gelb= alle Streams zum Soundserver; Orange=Ausgabestream zu Boxen/Kopfhörer; Rot=Ausgabestreams zu anderen Anwendungen. Was fehlt ist der alsa-Soundserver. Wichtig ist auf jeden Fall die Bedeutung des Soundservers klar zu machen.

Evtl hilft ja auch ein kleiner Hinweis, dass die die Erklärungen bewußt vereinfacht sind. Was meint ihr?

Ich bin immer für Vereinfachung. Auch wenn dabei manchmal etwas „nicht ganz richtig“ dargestellt wird.

Was meiner Meinung nach im Artikel zu kurz kommt, ist die Frage:

• Wer oder was ist für die Ansteuerung der Hardwareanschlüsse (LineIn, Boxen, 5.1 Sound, Mikro, Kopfhörer) zuständig? Nach meinem bisherigen Kenntnisstand würde ich sagen: Der Treiber bzw die Konfiguration über HDA. Bei PulseAudio oder Phonon kann ich aber auch solche Sachen einstellen?

kaputtnik schrieb:

Was meiner Meinung nach im Artikel zu kurz kommt, ist die Frage:

Wer oder was ist für die Ansteuerung der Hardwareanschlüsse (LineIn, Boxen, 5.1 Sound, Mikro, Kopfhörer) zuständig? Nach meinem bisherigen Kenntnisstand würde ich sagen: Der Treiber bzw die Konfiguration über HDA. Bei PulseAudio oder Phonon kann ich aber auch solche Sachen einstellen?

Nur kurz: ja, das ist Sache des Kernelmodules. Es erkennt, was für Fähigkeiten die Soundkarte hat, und stellt die Kanäle und Schaltmöglichkeiten bereit. Darüber sitzt als "Abstraktionsschicht" ALSA, das diese Eigenschaften der Soundkarte darstellt. ALSA stellt also Schnittstellen und Steuerregister bereit, um darüberliegenden Applikationen Zugang zur HW zu gewähren.

Bei PulseAudio oder Phonon kann ich aber auch solche Sachen einstellen?

Die benutzen die von ALSA zur Verfügung gestellten Möglichkeiten.

(LineIn, Boxen, 5.1 Sound, Mikro, Kopfhörer)

Da muss man sauber trennen: ALSA stellt Möglichkeiten der Soundkarte (die Sinn machen) anderen Applikationen zur Verfügung. Schlussendlich bedeutet das, das bei zB 5.1 + Stereokopfhörer von ALSA 8 Kanäle zur Wiedergabe bereit gestellt werden. Wie und ob ich die dann gruppiere und benamse ist frei definierbar, was von den Klickibunti-Soundservern reichlich genutzt wird.

Wohingegen hin- und herswitchen von Kanälen eine reine Sache des Routings ist, womit idR ALSA gar nix am Hut hat; es leitet lediglich die Audiostreams durch. Natürlich nur, falls die Soundkarte kein internes Routing bereit stellt (und das Kernelmodul dies unterstützt).

Je mehr wir hier diskutieren, desto verwirrender wird die Sache. - Wir sollten gar nichts ändern! 😉

Ich habe nun unter Baustelle/ALSA einen Artikel begonnen, der ALSA etwas näher unter die Lupe nimmt. Die Diskussion in diesem Fred hat ja deutlich aufgezeigt, dass da noch Erklärungsbedarf besteht. Ich hoffe auch, dass mit diesem Artikel im Hintergrund die Grafiken, die da kommen werden, entsprechend vereinfacht werden können. Gedanke: das Komplexe auslagern, um die Übersicht über das große Ganze nicht ausufern zu lassen.

Ok so?

😀

Ich dachte Du hast keine Zeit 😉

pepre schrieb:

Ich habe nun unter Baustelle/ALSA einen Artikel begonnen, der ALSA etwas näher unter die Lupe nimmt.

Habe ich schon gesehen 😉

Ich hoffe auch, dass mit diesem Artikel im Hintergrund die Grafiken, die da kommen werden, entsprechend vereinfacht werden können.

Ah, doch ein paar kleine Schemazeichnungen? Prima ☺ Willst Du die machen, oder soll ich mich dann nochmal bemühen?

Gedanke: das Komplexe auslagern, um die Übersicht über das große Ganze nicht ausufern zu lassen.

Jo, ist doch Prima 👍

kaputtnik schrieb:

Ich dachte Du hast keine Zeit

Habe ich auch nicht. Aber ich hatte keine Lust, mich mit LAMP zu beschäftigen.

Ah, doch ein paar kleine Schemazeichnungen?

Aber sicher. Ein Bild sagt mehr als 2^10 Worte ☺

Willst Du die machen, oder soll ich mich dann nochmal bemühen?

Das kannst du sicher besser als ich 😉

Ich habe auch den letzten Autor von Soundsystem angeschrieben: seine Ergänzungen passen ja viel besser in den ALSA-Artikel als in Soundsystem (was ja nur einen groben Überblick verschaffen ohne Verwirrnis durch zu viel Infos verschaffen soll).

🦆

Hallo,

den ALSA-Artikel bitte hier diskutieren: baustelle-alsa

Gruß, noisefloor

ESD (bei Kubuntu arts)

Ist das nicht schon laaange her? Letzte Version ist von 2006 wenn ich mich nicht täusche.

Bei GNOME ist dies GStreamer, bei KDE wird ab Version 4 Phonon verwendet.

Frage ist die Aussage so richtig ❓

Bei Unity und GNOME ist dies GStreamer, bei KDE wird ab Version 4 Phonon verwendet.

Das schließe ich aus der Aussage, dass bei GStreamer Ubuntu 12.04 „Precise Pangolin“ aufgeführt ist.

Wenn das richtig ist, ändere ich den Satz entsprechend der Markierung ab.

Hallo,

unter Ubuntu (egel, welcher Desktop) ist es Gstreamer.

Gruß, noisefloor