2-Kanal-Convolving mit Linux (Ubuntu)

[tinnitus]

Hallo Ulli,

die clients werden korrekt erzeugt. Das wird vom "Steckfeld" so generiert wie ich es einkopiert habe. Das funzt. Nur die <plugs> müßten noch analog mit einem RegEX Ausdruck wie im jack.plumbing definiert werden.

Ich hab auch versucht im Plug-Eintrag einen RegEX Ausdruckeinzutragen, wurde aber so nicht akzepteirt.
Ich weiss nicht wie die Plugs mit einem Zuordnung eines RegEX Ausdruckes im XML Format zugeordnet werden. Gibt s hier im Forum keinen XML "Guru"?

Gruß wieder auf Unterniveau angekommen
Roland

[tinnitus]

Hallo,

Ulli sei Dank für seine "Schulung". Jetzt hab ich es auch geschafft das Steckfeld zu "dynamisieren".

Dadurch ist jack.plumbing überflüssig geworden.

Beim Anlegen der Steckfeld (Patchbay) Einträge, ist für diejenigen Verbindungen, die jackaudiosink als Anschluss verwenden, der Eintrag folgendermassen anzupassen:



wichtig ist das dies im Bereich "Ausgang Anbindung Anschlüsse" vorgenommen wird. Dann muss es nachher so auschauen:



So jetzt bin ich zufrieden
Gruß Roland

[ujaudio]

Als Hardwarekomponenten kamen zu Einsatz:
- Siemens Notebook Lifebook E7010 und Dell Mini Netbook 9
- DAC Nuforce ICON HHP
- LS B&M BM20

Als Softwarekomponenten habe ich ausgewählt
- Betriebssystem Ubuntu 10.10
- Jack Audio Control
- Jconvolver
- diverse Audioplayer (Rythmbox, Aqualung, Alsaplayer, Flashplayer, ...)

Meine Musik-Dateien liegen auf einem NAS (Synology C407)

Hallo Roland,
bb ich mein ex-Dienstnotebook bekommen kann ist noch offen (das war auch ein E7010), aber ich habe noch ein Lenovo X60, auf dem zumindest die Ubuntu-Live-CD schon mal ganz gut lief. Unter Ubuntu hast du das USB-DAC zum Laufen bekommen. Damnzufolge könnte ich ja mal mein Glück probieren...

An alle Mitleser, gibt es auch Erfahrung mit einem Firewire-Gerät unter Linux? Ich muss mich vermutlich ganz tief einlesen (oder mal ein Gerät von Thomann holen, ist bei mir ja gleich um die Ecke). Welches aktuelle und eher preiswerte Gerät empfiehlt sich da? Auf den ersten Blick habe ich nur Geräte mit 32 und mehr Kanälen gefunden - obwohl ich ja nur 2 in + 2 out benötige.

Falls Uli mit liest: ist es realistisch anzunehmen, dass man die "bruteFIR" auf einem Notebook zum Laufen bekommt? Linux-Profis schaffen das vermutlich, aber meine Kenntnisse werden dazu wohl nicht ausreichen. Insofern sollte ich mich wohl eher an Rolands Ansatz versuchen.

Einen lieben Gruß
Jürgen

PS: Ich habe seit langer Zeit wieder einen XP-PC, sogar mit ehrlich gekaufter Lizenz - und er läuft, inklusive Audacity! Ist halt ein AMD mit lautem Lüfter...

[RC23]

@Ingo,
ich hab mal den Guayadeque Player installiert. Er gibt auch "dynamisch" über den Gstreamer aus.

Hallo Roland,

was meinst Du mit "Er (der Guayadeque Player) gibt auch "dynamisch" über den Gstreamer aus." ? Was soll mit dynamisch gemeint sein? Bin noch Linux Newbie, deshalb die Frage.

Wieviel GB sollte die Partition für eine Ubuntu-Installation haben rein für Musik? Ubuntu 10.10 besitzt eine Downloadgröße von 686 MB.

Grüße

Rüdiger

[tinnitus]

Hallo Rüdiger,

dynamisch heisst hier folgendes:

Manche Player ändern den Outputnamen, wenn man z.B. zum nächsten Musikstück springt. Da wird eine fortlaufende Nummer vergeben, oder für ein neues Stück wird ein neuer Outputname schon vor Beendigung desllaufenden Stückes vergeben. Wenn in Jack jetzt die Outputnamen fix vorgegebne sind, so bricht die Jack-Verbindung ab, da der neue Namen nicht bekonnt ist. Die Notation mit der [...] kann dann diese Folgenummerierung an Jack weitergeben. Eine reine Musik Ubuntu Partition hab ich ab 3GB am laufen. 4-5GB sind aber besser.

Ich hoffe es ist jetzt klarer was mit "dynamisch" hier gemeint ist.

Gruß Roland

[Pittiplatsch]

Hallo an alle Rhythmbox Nutzer!

Auch ich nutze derzeit Ubuntu und Rhythmbox. Trotz des hier beschriebenen Ansatzes bastel ich gerade daran ein eigenes kleines EQ project um meinen Frequenzgang gerade zu biegen. Die Anbindung mittels Plugin sind ja recht komfortabel und die Doku mittlerweile auch fuer GStreamer recht brauchbar. Mal schauen was am Ende rauskommt .
Die Anbindung von gstreamer bietet natuerlich noch ganz andere Moeglichkeiten - bin gerade erst am Rantasten.

Nur bloed das man zum Plugin debuggen immer Rhythmbox neu starten muss... - das bremst mich ein bisschen aus - ausserdem wuerde ich bei der Arbeit gerne Musik hoeren ...

[Pittiplatsch]

auch wenn ich wohl vermutlich mittlerweile der einzige verbliebene Rhythmbox Nutzer bin: die ersten Gehversuche scheinen Erfolversprechend: zumindest kan ich jetzt EQ baender definieren und es tut sich was. Ich habe auch schon Ansatzweise meinen Bass unterhalb von 40 Hz etwas gerade gebuegelt und eine bei 70Hz etwas gedrueckt.
Ich werde wohl aber nochmal mit den GStreamer leuten reden muessen - derzeit ist der parametrische SW EQ fuer mich noch eine Blackbox.
Ausserdem funktioniert meine UI Anbindung noch nicht : sprich ich kann den EQ nicht zur Laufzeit aendern: ziemlich unpraktisch wenn man jedesmal den player neu starten muss.
Naechste Baustelle auch noch persistente Abspeicherung der eingestellten Werte (derzeit hardgecoded). Sobald ich das im Griff habe werde ich wohl mal meine erste Version ins Netz stellen. Irgendwelche Ideen was man noch sinnvoll einbauen koennte?

[Pittiplatsch]

Die erste Version ist inklsuve UI Anbindung und persistenter Datenspeicherung fertig! Ich werde alsoerstmal selber spielen als sozusagen erster Tester bevor ich das Ganze dann spaeter ueber die Rhythmbox plugin Seite auf die Menschheit loslasse . 64 frei konfigurierbare Baender sind dafuer erstmal genug (freq,width,gain). Gstreamer bietet als parameter fuer jedes band noch Peak/Highshelf/Lowshelf an - ich habe erstmal hardgecoded 'Peak' - mal sehen : vielleicht bohre ich es spaeter noch auf.

Eine Erfahrung meinerseits zum lineare Bass: bei hoeheren Pegeln ist das wirklich sehr angenehm. Da ich aber oft sehr Leise hoehre ueberlege ich fast ob ich mich nicht spaeter noch an einer Loudness - Implementierung versuche.

[Pittiplatsch]

falls es noch wen interessiert: jetzt ist es auch offiziell released:

https://live.gnome.org/RhythmboxPlugins ... _Equalizer

Laeuft bei mir wunderbar unter Ubuntu 12.10/Rhythmbox 2.97. Besonders toll die weitestgehend undocumentierte Gtk 3.0 - python Schnittstelle - aber wo ist sonst der Spass . Der Support inm der open Source Community is super - schnellere Antworten auf Fragen als ich sie jeh im wirklichen Leben kriege...

Nach der Verfeinerung des EQ werde ich mir mal ueberlegen wie ich eine DRC als einfach bedienbares plugin bastel -> Ideen sind willkommen!

[Pittiplatsch]

Erstmal Danke an alle in diesem Thread: Zeit fuer den naechsten Schritt: wirkliche Faltung zu Korrektur! Ich habe diesen Schritt als Einstieg genommen um mal selber zu versuchen mittels JACK und jconvolver und bruteFIR mal zu schauen wie gut sowas funktioniert. Zur Erzeugung der Filter nutze ich DRC:

http://drc-fir.sourceforge.net/doc/drc.html

Das ganze ist fuer einen ersten Wurf gar nicht schlecht. Unter Ubuntu 12.10 gibt es ein paar Fallstricke - zunaechst Pulse runter und nur ALSA - ansonsten habe ich Jack nicht zum Laufen gebracht. Bei Gelegenheit und falls Bedarf besteht werde ich mal eine Anleitung schreiben (bevor ich vergesse was ich alles gemacht habe).

Naeschter Schritt: Jack und JConvolver/BruteFIR sind ganz nett aber doch recht frickelig. Ich werde mal schauen ob ich mittels des gstreamer FIR filters eine in Rhythmbox integrierte Loesung hinbekomme - aber das kann dauern. Zumindest hat das Einhaengen des Filters in die playback pipeline schonmal geklappt . Jetzt muss ich "nur noch" sehen wie ich von dem DRC erzeugtem pcm file zu den FIR Filterkoeffizienten komme...

[frankl]

Naeschter Schritt: Jack und JConvolver/BruteFIR sind ganz nett aber doch recht frickelig. Ich werde mal schauen ob ich mittels des gstreamer FIR filters eine in Rhythmbox integrierte Loesung hinbekomme - aber das kann dauern. Zumindest hat das Einhaengen des Filters in die playback pipeline schonmal geklappt . Jetzt muss ich "nur noch" sehen wie ich von dem DRC erzeugtem pcm file zu den FIR Filterkoeffizienten komme...

Hallo Tobias,

meinst Du mit dem letzten Satz, dass Du die FIR Koeffizienten als lesbaren Text (einen pro Zeile) brauchst?
Falls ja: Du kannst zum Beispiel sox benutzen, das im .dat Format ausgeben kann, dann noch den passenden Teil ausschneiden: Als Ausgabe von DRC hast Du vermutlich Dateien im FLOAT32_LE Format, richtig? Sagen wir, Dein Filter ist in der Datei myfilter.float, dann:

Code: Alles auswählen

sox -t raw -r 44100 -c 1 -e float -b 32 myfilter.float  -t dat - | grep -v "^;" |sed -e "s/  */:/g" |cut -d: -f3 > myfilter.txt

und die lesbaren Filterkoeffizienten stehen in myfilter.txt.

Natürlich kann man auch ein kleines Progrämmchen schreiben, das dies direkter macht (ich habe eins in C).

Zu jack, jconvolver, Rhythmbox kann ich nicht viel sagen, denn ich verwende zum Abspielen selbst geschriebene Skripte und kleine Programme (es werden unter anderem sox und brutefir benutzt).

Viele Grüße,
Frank

[Pittiplatsch]

Hallo Frank,

danke fuer die Info, ok, es ist also wirklich so das das pcm was ich z.B. von DRC bekomme 1:1 die Filterkoeffizienten enthaelt?
Wenn das so ist sollte ich auch hinbekommen das in Python auszulesen (meine bevorzugte Rhythmbox plugin Sprache). Dank Deiner Sox - Hilfe kann ich dann per des erzeugten Coeff files wunderbar ueberpruefen ob ich auch keinen Bloedsinn auslese .

Ich hadere gerade mit mir welchen Weg ich gehe:

1) Gstreamer Fir filter ist gut und schoen, so wie sich die Doku liesst aber nur ein FIR filter fuer beide Kanaele.
Da werde ich den freundlichen Autor nochmal befragen.
2) Frontend plugin was Jack und bruteFIR bzw jconvolve cfg files auitomatisch generiert und diese started

gibt es eigentlich im Ergebnis einen Unterschied zwischen jconvole und bruteFir? BruteFIR ist zumindest flexibler weil er direct auf alsa ausgeben kann (auch wenn ich das noch nicht hinbekommen habe - ich nutze immer noch jack)

Danke und Viele Gruesse,
Tobias

[frankl]

danke fuer die Info, ok, es ist also wirklich so das das pcm was ich z.B. von DRC bekomme 1:1 die Filterkoeffizienten enthaelt?

Hallo Tobias,
ja, genau so ist es. Das Format der Samples wird durch die Variable "PSOutFileType" in der Konfigurationsdatei (bzw. der Kommandozeilen-Option --PSOutFileType) bestimmt: F ist die Standardeinstellung und meint 32bit float, mit D sind es 64bit doubles und mit I sind es integers.

Wenn das so ist sollte ich auch hinbekommen das in Python auszulesen (meine bevorzugte Rhythmbox plugin Sprache). Dank Deiner Sox - Hilfe kann ich dann per des erzeugten Coeff files wunderbar ueberpruefen ob ich auch keinen Bloedsinn auslese .

Ich hadere gerade mit mir welchen Weg ich gehe:

1) Gstreamer Fir filter ist gut und schoen, so wie sich die Doku liesst aber nur ein FIR filter fuer beide Kanaele.
Da werde ich den freundlichen Autor nochmal befragen.
2) Frontend plugin was Jack und bruteFIR bzw jconvolve cfg files auitomatisch generiert und diese started

Ich kenne mit damit nicht gut aus, weil ich das nicht benutze. Aber aus der Dokumentation für "audiofirfilter" (das meinst Du mit 1), oder?) würde ich auch vermuten, dass das hier nicht brauchbar ist. Es sieht in der Tat so aus, dass nur ein Filter benutzt wird, der auf beide Kanäle gleich angewendet wird. Außerdem hat das Beispiel nur 32 Taps (im Vergleich zu den 2^16 oder mehr in den Filtern aus DRC), das ist eventuell auch von der Performance nicht brauchbar.

Bei 2) weiß ich nicht genau, was Du meinst. Gibt es nicht ein generisches Plugin für gstreamer, das es erlaubt, eine beliebiges Programm per Pipes in eine Pipeline einzubauen?

gibt es eigentlich im Ergebnis einen Unterschied zwischen jconvole und bruteFir? BruteFIR ist zumindest flexibler weil er direct auf alsa ausgeben kann (auch wenn ich das noch nicht hinbekommen habe - ich nutze immer noch jack)

Das Ergebnis sollte bis auf verschiedene Rundungsfehler das gleiche sein. Ich benutze "brutefir" immer als (UNIX-)Filter, also stdin und stdout für Ein- und Ausgabe. Für das eigentliche Abspielen benutze ich "aplay". Jedes Programm soll das machen, was es richtig gut kann.

Viele Grüße,
Frank

[Pittiplatsch]

HalloFrank,

Danke fuer die Hilfe!

Ich kenne mit damit nicht gut aus, weil ich das nicht benutze. Aber aus der Dokumentation für "audiofirfilter" (das meinst Du mit 1), oder?) würde ich auch vermuten, dass das hier nicht brauchbar ist. Es sieht in der Tat so aus, dass nur ein Filter benutzt wird, der auf beide Kanäle gleich angewendet wird. Außerdem hat das Beispiel nur 32 Taps (im Vergleich zu den 2^16 oder mehr in den Filtern aus DRC), das ist eventuell auch von der Performance nicht brauchbar.

ja das hat mir der Autor auch bestaetigt. Pertformancemaessig sollte es gehen hat er gemeint. Mein Plan ist also zunaechst mal zu versuchen es damit irgendwie zum Laufen zu bringen. Auf Basis der dort gesammelten Erfahrung werde ich dann mal sehen wie ich weiter mache.
Als simple Variante fuer einen Filter fuer beide Kanaele ohne Referenzkanal sollte es doch zumindest so gut sein wie z.B. Antimode um zumindest den Bass zu linearisieren.

Bei 2) weiß ich nicht genau, was Du meinst. Gibt es nicht ein generisches Plugin für gstreamer, das es erlaubt, eine beliebiges Programm per Pipes in eine Pipeline einzubauen?

wow das war ein bisschen mehr Aufwand als ich spendieren wollte . Am Ende waere halt eine Art DRC Designer plugin mit gleichzeitiger Anwendung der Filter ganz schick. Nun noch als eigenes gstreamer plugin - puh ganz schoen viel fuer ein Feierabendprojekt - also erwartet nicht bis morgen eine Fertigstellung .

Die Alternative waere halt ein UI fuer die measure scripts und DRC gewesen und eine Art UI - Setup hilfe fuer bruteFIR/Jack. Alles was es halt fuer einen Otto-normal user einacher/automatisierter handhaben laesst.

Eine Frage noch da du Dich gut auszukennen scheinst: ich habe gestern mal all Koeffizienten ausgelesen direct aus dem pcm (65535!!) - geht ueber ein paar Umwege auch in Python und mal direkt in den audiofirfilter gesteckt. -> klang sehr merkwuerdig .
Sind die Filterkoeffizienten schon im Frequenzraum oder muss ich die vorher noch per inverse FFT umwandeln wie in dem audiofirfilter sample?

Danke und Viele Gruesse,
Tobias

[frankl]

Eine Frage noch da du Dich gut auszukennen scheinst: ich habe gestern mal all Koeffizienten ausgelesen direct aus dem pcm (65535!!) - geht ueber ein paar Umwege auch in Python und mal direkt in den audiofirfilter gesteckt. -> klang sehr merkwuerdig .
Sind die Filterkoeffizienten schon im Frequenzraum oder muss ich die vorher noch per inverse FFT umwandeln wie in dem audiofirfilter sample?

Hallo Tobias,

die Filterkoeffizienten aus DRC sind im Zeitbereich, die können direkt zum Falten eines Mono-Streams(!) von PCM Daten benutzt werden.

Da ich nicht weiß (und auf die Schnelle nicht herausgefunden habe) was der audiofirfilter exakt macht, kann ich auch nicht wirklich sagen, warum es in Deinem Versuch merkwürdig klang. Zwei Ideen: Hast Du mit den Filtern aus DRC (etwa mit brutefir) schon Dateien gefaltet, die ordentlich klangen? Falls ja, und somit Deine Bedienung von DRC in Ordnung zu sein scheint: Trennt der audiofirfilter auch die Musikdaten in links und rechts auf, um darauf jeweils den Filter anzuwenden (diese Daten enthalten immer abwechselnd ein Sample für den linken und einen für den rechten Kanal)? (Falls der Filter direkt auf den Stereo-Stream angewendet würde, müsste man zwischen alle Filterkoeffizienten noch eine 0.0 einfügen.)

Viele Grüße,
Frank