Sound Visualisierung für die Konsole

M

miketech

Routinier
Hi,

Ihr kennt doch diese lustigen Visualisierungen/Effects unter XMMS und Co. Sowas suche ich für die Konsole. Und wenns geht, sollte es auf die aktuelle Audioausgabe direkt aufbauen und an keinen Player gebunden sein. Was ich vorhabe: Ich möchte unter X via Remote X Musik abspielen und auf der Konsole des Rechners, auf den ich zugreife diese Effekte anzeigen lassen.

Gibts sowas?

Gruß

Mike
 
Ne noch nie vorher gehört. Ich glaube sowas schonmal irgendwo gesehen zu haben. Ich weiß nur leider nicht mehr wo.

Mike
 
Sollte nicht das Problem sein, wenn ihr nur ein bestimmtes Plugin, oder eine bestimmte Visualisierung portieren wollte. Wuerde euch dann unterstuetzen.
 
So. Hab mir mal aalib angesehen. Von der Doku schonmal recht mager. Dennoch nicht sonderlich kompliziert zu nutzen in C.

Man erstellt sich einen context und kann Daten in diesen wie in einen simplen Grafik-Speicher schreiben, dass dann rendern und ausgeben. Problematisch dabei allerdings, dass es nicht sonderlich schnell auf den Beinen sein wird, was allerdings auch vom verwendeten Algorithmus fuer das Beschreiben und (teilweise) Rendern der Grafikdaten abhaengt.

Das Hauptproblem in meinen Augen ist, an die Audiodaten zu kommen. Ich wuesste keine Moeglichkeit ohne weiteres als Benutzer, oder root auf die Ausgabe der Audiodaten fremder Programme zuzugreifen.

Alternativ muesste das Program entweder als Effect-Plugin von XMMS (mal angenommen wir sprechen von XMMS) geschrieben werden, welches dann als daemon die Daten anderen Programmen bereitstellt, oder sie direkt verarbeitet und in Grafik-Daten umsetzt. Auch moeglich waere die Umsetzung als Vizualisation-Plugin. Allerdings koennt ihr nicht einfache Console erstellen, in der die Daten dann ausgegeben werden. aalib kann zwar selbst Fenster erstellen, jedoch ist das nicht das, was ich mir vorstelle.

Mein Favorit waere das Effect-Plugin, wenn keine eine Idee hat, wie die Daten sonst im System zwischen Programmen und Ausgabe abgefangen werden koennen. Fifos statt /dev/dsp eignen sich uebrigens nicht sonderlich. Je nach Aufwand ein Effect-Plugin zu schreiben koennte auch direkt ein Stueck Code in den mpg123 von XMMS implementiert werden, welcher die Daten parallel zum Device ausgibt. jedoch laeuft man dann Gefahr, dass dies mit jeder neuen Version von XMMS geaendert wird und zu anderen Versionen zu der des Autors angepasst werden muss.

Mal schauen, wie viel Aufwand die implementation eines abzweigenden Effect-Plugins beansprucht.

mfg
 
Fein. Nehmen wir statt dem Effect- ein Viz-Plugin und ich bin gluecklich. Der Aufwand haelt sich Arg in Grenzen.

Das System besteht demnach aus drei Teilen.
  • dem XMMS Plugin, welches die Daten von XMMS erhaelt (freq/pcm?) [C]
  • einem XMMS (Worker-)Thread, welcher die Daten ueber die IPC (shm+sem?) anderen Prozessen zur Verfuegung stellt* [C]
  • eine Prozess, welcher die Daten dann rendert und darstellt [C/C++?]
* optional

Alternativen, Vorschlaege, ...? Jemand der beim Umsetzen helfen moechte??? :)

mfg und gn8
 
Da hätte ich auch Interesse. ;)
Ich hab mich vor einem Monat schon mal mit aalib gespielt. Mit XMMS Plugins hab ich mich noch nicht beschäftigt, aber das macht sicher Spaß.
Ich muss mir das mal heute Abend, wenn ich von der Arbeit wieder zu Hause bin, angucken.
 
Die view main-themes des programms sind das ...
  • XMMS Plugin
  • die IPC mit Semaphoren und Shared Memory fuer die Syncronisierung
  • die Visualisierung in einen Analyzer, oder Scope
  • die Darstellung mit aalib

XMMS Plugin ist nicht das grosse Problem. (http://www.xmms.org/docs/vis-plugin.html)

Die IPC bereitet mir noch unbehagen. Hab zwar frueher haeufig damit gearbeitet, jedoch immer Probleme gehabt entsprechende Auffangroutinen zu implementieren. Die Komunikation und Umsetzung an sich sind nicht sonderlich schwer.

Visualisierung in Scope/Analyzer hab ich noch grob keinen Plan von. Analyzer duerfe mit den Frequenz-Daten (__u16 [n_channels][n_freqs]) vom XMMS Plugin nicht schwer fallen. Ansonsten gibt es da entsprechende Plugins um einen Algorithmus zu extrahieren.

Die aalib an sich finde ich auch nicht sooo schwer. Zumindest wenn man die Steuerung er Parameter auf die Kommandozeile, und den Environment schiebt. :) Beachtet werden sollte in diesem Zusammenhang, dass die Visualisierung die Ausgabegroesse beruecksichtigt (schneller), oder diese spaeter nochmal angepasst wird (langsamer).

Waere toll wenn du mitmachst. Welche Themen duerfen es denn sein? :)

mfg
 
Zuletzt bearbeitet:
An den Sound kommt man mit vsound.
Ist es eine Textmode- oder einen Framebuffer-Konsole? Wenn ersteres, was spricht gegen letzteres?

-khs
 
vsound waere eine Moeglichkeit. Auch wenn mir nicht behagt, dass alle Programme dann "ueber" vsound laufen.

Stellt sich nun die Frage, wie die Architektur des Systems entsprechend an vsound angepasst werden soll. Alles bisherige (xmms) mal aussen vor.

Am einfachsten waere es, direkt mit vsound (als Helferlein) die Visualisierung umzusetzen. Der Benutzer wuerde dann Programme die er visualisieren moechte, entsprechend starten.
Code:
visualize [opts] xmms [xmms-opts]
visualize [opts] mplayer [...]
visualize [...] ...

Hinzukommen wuerde dabei dann eine Komponente, welche die Ver- und Aufwertung der Daten vornimmt, ueber der Funktionalitaet heraus, die vsound bietet.

Wir muessten zuerst die Frage klaeren, wie das Programm genutzt werden soll. Jedesmal ein Programm zu starten, etwa xmms, oder mplayer, nur um dann eine Visualisierung zu haben, ist das gegenteil von usability. Hingegen nimmt der Aufwand erheblich zu wenn, wir es anders machen und zu jeder Zeit der Benutzer die Visualisierung starten, oder beenden kann.

Ist es eine Textmode- oder einen Framebuffer-Konsole? Wenn ersteres, was spricht gegen letzteres?
Keine Ahnung. Mir fehlt das noetige know-how um das abzuschaetzen, zumal ich keinen framebuffer zur Verfuegung habe. Wenn sich jemand findet mit dem noetigen Wissen, koennen wir gern darueber reden. :)

mfg
 
Zuletzt bearbeitet:
khs schrieb:
Ist es eine Textmode- oder einen Framebuffer-Konsole? Wenn ersteres, was spricht gegen letzteres?
Wenn wir die aalib verwenden, funktioniert das auf fast jeder Art von Textkonsole. Es wird auch auf einer Linux Framebuffer-Konsole funktionieren. Der einzige Unterschied zu einer "normalen" Konsole ist, dass man die Auflösung manuell einstellen kann. ;)

Wegen vsound & Problem der usability:
Ich weiss aber nicht, wie man ohne solche Wrapper wie vsound an den Soundstream kommt bzw. ob das überhaupt möglich ist. Es wäre natürlich sehr praktisch wenn man das Programm zu jeder Zeit wenn von irgendeinem Programm grade Sound abgespielt wird starten kann.

EDIT:
Alsa hat ein PCM-Loopback-Device: http://linuxfromscratch.org/pipermail/blfs-support/2002-November/030726.html
(Ich liebe Google :D)

Kanns aber leider noch nicht testen.. wir haben hier keine Linux-Maschinen...
 
Zuletzt bearbeitet:
also erstmal muss ich sagen, etuli, dein engagement hier finde ich super :respekt:
ich hätte nicht gedacht, dass sich so einer so schnell versuchen wird sich einzuarbeiten in aalib.
adridon, dir danke ich natürlich auch :) :respekt:

Ist es eine Textmode- oder einen Framebuffer-Konsole? Wenn ersteres, was spricht gegen letzteres?

also ich weiss nicht genau was ihr meint, aber falls es um die konsole geht auf der nachher die visualisierung stattfinden soll, denke ich wäre es doch am besten die bash zu nehmen.

leider habe ich nicht das know-how um beim coden mitzumachen, ich könnte mich wahrscheinlich nur als tester anbieten :(
 
oyster-manu schrieb:
adridon, dir danke ich natürlich auch :) :respekt:
Hmm? Macht der auch mit? Kann der überhaupt programmieren? ;)

oyster-manu schrieb:
also ich weiss nicht genau was ihr meint, aber falls es um die konsole geht auf der nachher die visualisierung stattfinden soll, denke ich wäre es doch am besten die bash zu nehmen.
Shells haben mit dem eigentlich nichts zu tun. Es wird prinzipiell einfach nur der Text für die Visualisierung von aalib ausgegeben und das ist sowohl shell- als auch konsolenunabhängig. (xterm, framebuffer, ...)
 
huch, ich hab irgendwie deinen mit adridons avatar verwechselt. warum habt ihr auch beide so schwarze pinguine? :)
 
thorus schrieb:
Shells haben mit dem eigentlich nichts zu tun. Es wird prinzipiell einfach nur der Text für die Visualisierung von aalib ausgegeben und das ist sowohl shell- als auch konsolenunabhängig. (xterm, framebuffer, ...)

Na gut, der Framebuffer kann auch mit 80x24 angesprochen werden, klar, aber ansonsten haette er auch noch alle sonstigen VESA-Aufloesungen zur Verfuegung. Dank fbset(8) kann man auch on-the-fly die Aufloesung wechseln. Falls das Plugin in 640x480 irgendwie fluessiger laufen sollte... ;)
Wenn natuerlich keine fb-faehige Konsole zur Verfuegung steht, nuetzt das schoenste fb-Plugin nichts.

Vielleicht sollte es einfach als Auswahlmoeglichkeit dazu. Irgendwo muss das Bild, was die aalib in ascii art umsetzt, ja sowieso herkommen. Ob man es, bevors zur aalib geht, noch schnell via commandline-Switch an den Framebuffer schickt oder nicht, ist dabei doch eigentlich egal. Oder wird dann auch nur in maximal Konsolenhoechstaufloesung berechnet?

Zum ALSA-loopback finde ich auf Anhieb gerade nur recht alte Dokumentation, aber das koennte in der Tat ne echte Alternative zu vsound sein.

-khs
 
http://linuxfromscratch.org/pipermail/blfs-support/2002-November/030726.html schrieb:
So, one needs to use & configure this loopback thingy. I think it would
collaborate with arecord, which is good enough for me.
But does anybody know anything about it? Is it supported by
alsa-0.9.0rc3? How to configure it? What devices are to made (with my
ens-1371 type card I have only

controlC0 midiC0D0 pcmC0D0c pcmC0D0p pcmC0D1p timer

sound devices (with alsa), and there is no thing like pcmloopD0S0c,
pcmloopD0S0p). How to edit the /etc/moduls.conf file, and the
/etc/asound.state file to make it work, what pcm's are to be define
In der Situation befinde ich mich auch. Kein loopback zu finden weit und breit. ;o)

Eine von den Audio-Daten erzeugenden Programmen unabhaenige Variante sagt mir aber am meisten zu. Vorausgesetzt sie ist anwendbar auf der Mehrheit der linux-systeme. :)
 
Ich kann keine entsprechende Schnittstelle finden, um sich in ALSA einzuhaengen. Zumindest ohne weiteres nicht. Als einzige moeglichkeit sehe ich die LADSPA. Und selbst das ist nicht ohne weiteres moeglich. Ueber das pcm loopback finde ich garnichts. Selbst in den alsa kernel quellen, noch in den alsa-lib quellen etwas.

Also wieder zurueck zu Wasser und Brot. vsound fuer alle, oder xmms-plugin fuer xmms?

mfg
 
Hab mal ne Scope-Umsetzung als xmms-plugin gebastelt. Eine Art Prototyp, um Aufschluss ueber den Aufwand und die Qualitaet der Ausgabe zu bekommen. Und ich muss a) sagen, dass die Umsetzung als Plugin wirklich sehr einfach war und die Ausgabe auch extrem interessant aussieht.

Boese nur ... die Umsetzung frisst die CPU! ;)

Das Plugin baut auf das dem xmms source paket mitgelieferte 'blur scope' plugin auf. Der Umfang vom Code ist ungefaehr der gleiche (~250 Zeilen).

Beispiel-Ausgabe, siehe Anhang. Allerdings laesst sich dies fuer ein Terminal nutzen, da die Daten dann durch stdout von xmms gejagt werden wuerde. Und wer macht sich schon die Muehe und startet xmms fuer die shell? :)

Den Code werde ich im Laufe der Nacht posten, wenn nichts dazwischen kommt.

mfg
 

Anhänge

  • aaplugin_blur.png
    aaplugin_blur.png
    35 KB · Aufrufe: 17
Das mit der CPU Nutzung koennte sich als grosses Problem herausstellen. Dem 'blur scope' Plugin liegt auch eine ASM Version der blur-Routine bei. Ob das allerdings das Problem loesst wage ich zu bezweifeln. Hab jetzt das Programm nicht profiled, aber ich vermute aalib konsumiert den Loewenanteil.

Hier erstmal der Code: http://dev.webreeze.de/projects/aascope/aaplugin.c

Kompilieren laesst sich das Ganze mit ...
Code:
gcc -shared -o aaplugin.so  `aalib-config --cflags --libs` `xmms-config --cflags --libs` -O3 aaplugin.c -Wall

Installieren dann mit ...
Code:
cp aaplugin.so `xmms-config --visualization-plugin-dir`
Solltet ihr entsprechende Rechte fuer bereithalten. Das Plugin koennt ihr dann wie jedes andere in XMMS auswaehlen unter den Visualization-Plugins (ctrl-v).

Das Plugin neigt dazu abzustuerzen. Was allerdings an verschiedenen Faktoren liegt. Einerseits daran, dass ich bei den Routinen des alten Plugins nicht sonderlich auf deren interne Implementierung geachtet habe, andererseits aber auch daran, dass wohl intern einige Dinge sich in die Quere kommen. Das Plugin neigt bsw. auch dazu sich aufzuhaengen, wenn es deaktiviert wird.

mfg
 

Ähnliche Themen

USB-Sound kackt nach einer Weile immer ab

Zurück
Oben