Entwicklung eines freien LS-Messprogramms

Moin,

die Bibliothek baut nun auch vorbehaltslos unter Windows. Linux habe ich nicht getestet, weil meine Ubuntu-Installation quer hängt und ich mir nicht die Arbeit der Neuinstallation machen will. Wär nett, wenn das mal jemand testen könnte. Einfach den aktuellen Code aus dem CVS ziehen, da steckt ein "Makefile.Linux" was gehen sollte. Zum Bau wird SWIG ( http://www.swig.org ) und Portaudio benötigt, beides ist bei den meisten Distributionen leicht erreichbar, vermutlich sogar schon installiert.

Leider hat Portaudio zumindest bei mir immer noch das Problem mit unheimlich hohen Latenzen (~500ms). Die kann ich zwar im Sourcecode runterdrücken (auf ~100ms), aber dann wird aus den Messungen nichts gares. Das kann aber genausogut an meiner Soundkarte oder Windows liegen.

<Edit>
was ich vergessen hab zu sagen:
für einen ordnungsgemäßen Betrieb sind sowohl gnuplot als auch eine amtliche Tcl/Tk-Distribution notwendig. Gnuplot gibts hier: http://www.gnuplot.info
Tcl/Tk hier: http://www.tcl.tk , eine komplette Windows-Distribution mit allem drum und dran hier: http://www.activestate.com/Products/activetcl/

Es ist auch nicht verkehrt, sich mal ansatzweise mit der Programmiersprache Tcl auseinanderzusetzen. Die ist wirklich einfach.

Gruß
Cpt.

Hi Cpt.

habe gerade die CVS-Version auf Gentoo-Linux compiliert. Laeuft ohne groessere Probleme. Einzige Aenderung:

gnuplot in /usr/bin anstatt /usr/local/bin
wish in /usr/bin anstatt /usr/local/bin

Das Interface sieht so weit sehr schoen aus! Ich bin allerdings noch nicht dazu gekommen, ausgiebig mit dem Programmen zu spielen.

Cheers,
c2007

PS: Nach einem ersten Blick in den TCL-code muss ich sagen das ich Python/TCL sehr viel uebersichtlicher finde. Aber das mag Geschmackssache sein.

Moin,

das ist doch fein, die Pfadangaben sind ja eher Nebensache und leicht zu ändern. Vielleicht mache ich auch noch ne Konfigurationsdatei, dann wird das noch ein wenig übersichtlicher.

Auf die Codeübersichtlichkeit würde ich nicht allzuviel geben, ich weiß dass die in den Beispielen nicht gerade famos ist. Das geht sicherlich noch schöner.

Ich habe Tcl gewählt, weil die Sprache an sich wirklich einfach ist und sich gerade für Programmieranfänger sehr gut eignet. Ganz im Gegensatz zu Perl, was zwar auch alles kann, aber für mein Empfinden dann doch mal zu kompliziert wird. Python habe ich bisher immer nur mal einen kurzen Blick drauf geworfen und mich nie richtig mit beschäftigt, wird sicherlich mal Zeit.

Prinzipiell müsste die API aber auch für Python gehen, SWIG kann dafür einen Wrapper erzeugen.

Gruß
Cpt.

Moin,

die neueste Version ist raus. Webseite wie immer: http://esweep.berlios.de

Es hat noch ein paar kleine Änderungen gegeben, deshalb (besonders @c2007) nehmt die neuesten Skripte die über die Webseite erreichbar sind. Ich habe da auch ein paar Kommentare eingefügt die die wichtigsten Konfigurationsoptionen beschreiben (und wer die anderen anrührt ist selber schuld :D)

Edit:
meine Ankündigung hat wohl zu einem Sturm auf den Berlios-Server geführt, der ist nämlich zusammengebrochen

Deswegen kann man diese feine Stück Software aktuell auch hier beziehen: ftp://fabricius.homeip.net/pub
Ist aber ein sehr langsamer Server.

Die Webseite ist dort jetzt auch in komprimierter Form als docs.tar.gz zu finden.

Gruß
Cpt.

Moin,

ich hab das noch nicht gezeigt, aber das Skript impulse.tcl beinhaltet auch ein rudimentäres Overlay-Management. Damit lassen sich beliebig (? ich hab noch nie richtig viele ausprobiert, aber eine Grenze habe ich nicht eingebaut) viele Impulsantworten übereinanderlegen und auch addieren. Das resultierende Frequenzgang-Dia sieht dann z. B. so aus:



Da habe ich einmal den HT (rot) gemessen, dann den TT (braun), und einmal die Summe berechnet (grün) und einmal gemessen (blau). Passt doch prima, nich?

Edit:
eben fragte jemand auf der OpenBSD-Mailingliste, ob nicht jemand ein Programm kennt, dass über die Soundkarte das abspielt, was in sie reingeht. Ihr könnt Euch denken, was ich geantwortet habe?

Richtig, ich habe ein wenig internationale Werbung für esweep gemacht. Das von mir gepostete Skript sieht so aus:


# load module
load /usr/local/lib/esweep.so esweep

# samplerate
set samplerate 44100

# buffer size
set size 16384

# prepare in-/ouput buffers
set au_in [esweep_create "audio" $samplerate $size]
set au_out [esweep_create "audio" $samplerate $size]

# open soundcard
set au_handle [esweep_audioOpen "/dev/sound" $samplerate]

# forever
while {1} {
# record and play
esweep_audioMeasure $au_in $au_out $au_handle
# switch buffers
set tmp $au_in
set au_in $au_out
set au_out $tmp
}


Fuckin' simple.

Ich habe ja die Hoffnung, dass man damit auch den Frequenzgang entzerren kann. Da muss man aber mit der Faltung etwas tricksen. Ich werde das mal bei Gelegenheit ausprobieren.

Gruß
Cpt.

Moin moin Cpt.

v4.0 laeuft auch unter Linux wie gewohnt gut. Die Overlays sind wirklich 'ne feine Sache, z.B. um auf einen Blick zwei Messungen zu vergleichen ohne umstaendlich auf ein anderes Programm umzusteigen.

Allerdings waere z.B. ein Eintrag ins Makefile oder ein "config.tcl"-file fuer die Pfadangaben wirklich praktisch.

Wenn ich dein kurzes Skript hier richtig verstanden habe, dann muesste es "Papagei.tcl" heissen, und mit der Buffergroesse koennte man die Verzoegerung einstellen.

Ich werde bei Gelegenheit versuchen mit Swig und Python zu spielen. Es gibt uebrigens auch einen Python-Wrapper fuer Gnuplot, so dass der Umweg ueber Script-files wegfallen wuerde. Wenn's klappt, dann sag ich hier Bescheid. Allerdings ist "bei Gelegenheit" bei mir leider ein reichlich dehnbarer Begriff.

Ich jetzt hauptsaechlich an Raumakustik interessiert, aber halt nach wie vor blutiger Anfaenger. Mal sehen ob ich da etwas Brauchbares zusammenstricken kann.

Cheers,
c2007

Moin,

c2007 schrieb:

v4.0 laeuft auch unter Linux wie gewohnt gut.

Die Overlays sind wirklich 'ne feine Sache

Alles nur geklaut Andere Programme können das ja auch. Allerdings finde ich es schön einfach.

Allerdings waere z.B. ein Eintrag ins Makefile oder ein "config.tcl"-file fuer die Pfadangaben wirklich praktisch.

Im Makefile nicht, weil das nichts mit dem GUI zu tun hat (oder man macht ein spezielles Makefile für die GUIs). Aber ein config.tcl ist ne gute Idee, dann macht man einfach ein


source config.tcl


und hat gleich alle nötigen Variablen eingelesen. Im Programm muss man dann eben nur darauf zugreifen.

Wenn ich dein kurzes Skript hier richtig verstanden habe, dann muesste es "Papagei.tcl" heissen, und mit der Buffergroesse koennte man die Verzoegerung einstellen.

Richtig.

Es gibt uebrigens auch einen Python-Wrapper fuer Gnuplot, so dass der Umweg ueber Script-files wegfallen wuerde.

Hmja, der kommuniziert wahrscheinlich über ne Pipe mit gnuplot. Ich hab das mal bei meinen Perl-Experimenten gemacht, irgendwie hat das aber nicht so geklappt wie ich mir das vorgestellt habe. Allerdings besteht da durchaus die Hoffnung, dass sich dadurch die Darstellung auch leichter verändern lässt, also Achsen/Skalierung ändern und so.

Die Einbindung der Grafik bei den verfügbaren GUIs erfolgt ja über ein Tcl-Skript, das von gnuplot geschrieben wurde. Finde ich eigentlich ziemlich elegant, und schnell ist es auch. Leider kann der Ausgabetreiber von gnuplot keine Farbverläufe in die Tk-Canvas zeichnen, deswegen ist beim burst decay so ein seltsamer Contour-Plot zu sehen, und kein Spectrogramm was ich eigentlich wollte.

Gruß
Cpt.

Moin,

ich habe eine Mailingliste eingerichtet, auf der sich trefflich diskutieren lässt (vor allem übersichtlicher als hier). Die ist für Nutzer gedacht, also Fragen zur Verwendung der Programmbibliothek, Vorstellung eigener Skripte, Fragen zu bestehenden Skripten, etc.

Anmelden geht hier: https://lists.berlios.de/mailman/listinfo/esweep-users

Gruß
Cpt.

Das mit der Mailinglist finde ich eine klasse Idee, ich werde sicherlich Fragen haben ,sobald ich das Ganze auf Win-Xp zum laufen bekommen habe...

Diese Nachricht wurde automatisch erstellt!

Das Thema wurde aufgeteilt und einige themenfremde Beiträge wurden verschoben. Das neue Thema lautet: "Fragen zu esweep, dem freien LS-Messprogramm"

Moin,

nach langer, langer Zeit komme ich so langsam mal wieder in den Genuss, an esweep weiter zu arbeiten. In der Zwischenzeit sind so einige Ideen gekommen und gegangen, im Ergebnis folgender Schluss:

ich werde noch mehr in Richtung Agilent VEE/LabView gehen. Das heißt, es wird fertige Funktionsblöcke geben, die möglichst unkompliziert aneinander gehängt werden können, um ein fertige Programm zu erzeugen. Und genau für so etwas eignet sich, nach zahlreichen Versuchen, die Skriptsprache Tcl perfekt.

Letztlich soll es auch eine grafische Entwicklungsumgebung geben, eben ähnlich wie VEE/LabView. Das ist aber noch Zukunftsmusik.

Der nächste Schritt wird sein, die Grundlagen zu schaffen. Ein großer Teil ist schon geschafft, das meiste aus der aktuellen Version kann ich recyclen. Der wichtigste Punkt wird sein, dass ich die Typisierung flexibilisiere, es wird andere Datentypen geben, die etwas allgemeiner gehalten sind. Das sind:

- Skalare
- Arrays
- Matrizen

Das ist die oberste Ebene, darunter teil sich das ganze noch auf:

- Int32
- Int64
- Real32
- Real64
- Complex32
- Complex64

Eigentlich bekannte Datentypen, das Kürzel 32/64 am Ende bedeutet die Wortlänge.

Für alle diese Datentypen werde ich die Grundrechenarten sowie die für die Signalverarbeitung grundlegenden (und ein paar für LS-Messungen wichtige) Methoden implementieren. Dadurch sollte es eigentlich möglich sein, sehr viel zu erreichen. Andere Methoden sollen nach und nach folgen.

Das nur ein kurzes Update. Ich kann nicht sagen, wann ich fertig bin. Wer Unterstützung leisten möchte ist willkommen.

Cpt.

Hi,

Wer Unterstützung leisten möchte ist willkommen.

ich spiele gerne den Beta-Tester. Programmieren ist nicht gerade mein Fachgebiet, da reichts gerade für MatLab und Co..

Harry

Hi,

Ich hab mich nach einiger Zeit mal wieder dem Messen zugewandt, bzw, bis zum eigentlichen Messen bin ich noch gar nicht gekommen. Windows gibt's seit einiger Zeit nicht mehr bei mir, also musste ich mir erstmal ein Messprogramm unter Linux suchen. Da ich früher schon von deinem esweep gelesen habe, dachte ich, versuch's doch mal.
Nun, ich benutze ArchLinux, welches ein großartiges User-Repository hat und ich wollte schon seit längerem mal Maintainer für ein Paket spielen. Also mal versucht ein sg. PKGBUILD zu schreiben, eine Anweisung für den Paketmanager von Arch ein Paket aus deinem src zu erstellen.

Nun ist dein Make-file aber ziemlich strikt, was es mir etwas schwierig macht. Ich würde daher vorschlagen 1-2 Dinge zu ändern, damit es standardmäßig funktioniert.

Hier das neue Makefile.Linux

Makefile.Linux schrieb:

PREFIX=/usr GCC=gcc CFLAGS=-O2 -Wall -I./include -I$(PREFIX)/include/tcl8.4 -DPORTAUDIO -msse -mfpmath=sse -fpic LFLAGS=-shared -L$(PREFIX)/lib -lportaudio -lm INSTALL_PATH=$(PREFIX)/lib all: clean tcl lib tcl: swig -tcl8 -o src/esweep_wrap.c "include/esweep.i" lib: $(GCC) $(LFLAGS) $(CFLAGS) -o esweep.so src/esweep_wrap.c \ src/esweep.c \ src/fft.c \ src/dsp.c \ src/esweep_conv.c \ src/esweep_math.c \ src/esweep_mem.c \ src/esweep_generate.c \ src/esweep_file.c \ src/esweep_sound.c \ src/sound_pa.c \ src/esweep_dsp.c \ src/esweep_surface.c install: mkdir -p $(DESTDIR)$(INSTALL_PATH) cp esweep.so $(DESTDIR)$(INSTALL_PATH)/esweep.so clean: rm -f esweep.so src/esweep_wrap.c

Ok, ich würde nicht /usr/local/lib benutzen, das Verzeichnis existierte vorher nicht bei mir. Wenn ich mir mein System anschaue, finde ich alles in /usr/lib, also warum auch nicht dein Programm.
Und das $(Destdir) brauche ich, damit ich das Programm zunächst im Paket installieren kann, welches dann später an seinen eigentlichen Ort installiert wird (vom Paketmanager pacman). Stört aber nicht, wenn man bei "make install" kein Verzeichnis übergibt, wird dein Standardverzeichnis verwendet.

Ah ja, ein Slash war zu viel bei deinem PREFIX.

So, soweit fürs erste, jetzt muss ich mir mal deine Skripte anschauen. Wenn das Programm weiter fortschreiten soll, würde ich vorschlagen, die Skripte irgendwie in das Paket zu integrieren, so dass nur noch die Installation eines Paket notwendig ist. Ich weiß, dass das nicht deine ursprüngliche Intention war, aber ich glaube auch nicht, dass du dir die ganze Arbeit nur für dich gemacht hast. Irgendjemand anderes sollte es schon auch benutzen! Und da (fast) alle Leute faul sind...

Viele Grüße,
Karlyzo

P.S. Achja, wäre schön, wenn du md5sums bereitstellen könntest.

Ich hab grad mal nur meinen Laptop-lautsprecher gemessen...Nachdem ich rausgefunden habe, wie man tk startet...aber, hey, ich bin immer noch baff.
Nicht unbedingt über meine Quäker, aber das Programm...alter Schwede, Ich hab großen Respekt vor dir!

Eins nur, c2007 hats schonmal geschrieben,
gnuplot finde ich in /usr/bin nicht in /usr/local/bin

wo "wish" in deinem Script/Homepage auftaucht, hab ich noch nicht gesehen, aber das liegt bei mir auch in /usr/bin.

BTW, wie kommt man darauf, dass der Befehl für tk "wish" heißt?

Moin,

danke für die Arbeit. Das Makefile ist tatsächlich viel zu unflexibel gestaltet. Das passiert, wenn man ein wenig Zeitdruck hat und wenig Lust, sich um jede Distro zu kümmern.

Bei OpenBSD werden alle externe Programme und Bibliotheken nach /usr/local geschoben, daher noch dieser Prefix. Bei manchen Linux-Distros ist das auch so.

"wish" kommt übrigens von "windowing shell". Und ja, ich habe mich auch gewundert.

Cpt.

Was hälst du von der Idee, ein Script zu schreiben, welches ein Fenster generiert, von dem aus man dann die anderen Scripte ausführen kann. Das könnte man dann verlinken und man hätte Zugriff auf "alle" Skripte über ein einziges Desktop-Icon oder ähnliches. Die Funktionalität bleibt bestehen, da man immer noch die Skripte selbst verändern kann, aber die Benutzerfreundlichkeit wäre um einiges gesteigert. Evtl. könnte man nach Schließen eines der "unter-skripte" wieder auf das "main-window" zurückgeführt werden.
Wenn du keine Lust dazu hast, kann ich mich da auch mal ransetzen, so schwierig sieht Tcl/Tk nicht aus. (Zumal man schnell sieht, was man macht).

Ich hab leider noch nicht ganz raus, wie andere Linux-programme ihren Pfad festlegen. Das läuft über ./configure , aber ich hab noch keine Plan, wie ein config-skript dann auszusehen hat.

Wenn du dein Makefile angepasst hast, sag Bescheid, dann kann ich esweep in das user-repository von Archlinux einbinden.

Was sind eigentlich deiner Meinung nach die Vorteile von BSD-Derivaten gegenüber Linux?

Karlyzo

Moin,

Karlyzo schrieb:

Was hälst du von der Idee, ein Script zu schreiben, welches ein Fenster generiert, von dem aus man dann die anderen Scripte ausführen kann.

prinzipiell ist das eine gute Idee, aber das ist etwas, was der Nutzer sich selber machen kann. Ich werde mir die Arbeit nicht machen.

Ich hab leider noch nicht ganz raus, wie andere Linux-programme ihren Pfad festlegen. Das läuft über ./configure , aber ich hab noch keine Plan, wie ein config-skript dann auszusehen hat.

Ich auch nicht. Und, ganz ehrlich, es interessiert mich auch nicht sonderlich. Wenn ich mir anschaue, was schon bei ganz kleinen Projekten für ein Aufwand mit dem ./configure gemacht wird, dann wird mir ganz anders. esweep hat sehr wenige Abhängigkeiten, und die lassen sich sogar noch sehr einfach per statischem Makefile verarbeiten.

Was sind eigentlich deiner Meinung nach die Vorteile von BSD-Derivaten gegenüber Linux?

Die gleichen Vorteile, die Linux gegenüber Windows hat. Mit den Nachteilen verhält es sich allerdings genauso.

Cpt.

Moin,

wenn die Konkurrenz gedacht hat, hier passiert nichts mehr, dann hat sie sich aber gewaltig geschnitten!

Ich hatte ja irgendwann mal angekündigt, das ganze eher in Richtung LabView/VEE zu verschieben. Diese Idee ist nicht gestorben, allerdings der Weg dorthin ein anderer.

Da meine Freizeit stark begrenzt ist, wird ein kompletter Rewrite nicht möglich sein - das kostet zu viel. Also geht es jetzt erstmal in kleinen Schritten vorwärts.

Ironischerweise kommt mir dabei mein Freizeitbegrenzer zu Hilfe - meine Arbeit. Dort sind in verschiedene kleine Programme Teile von esweep geflossen, und manchmal musste ich esweep auch erweitern. So musste ich dann mal auf die Schnelle einen Wavefile-Import/Export schreiben. Und eine grafische Darstellung. Das muss ich jetzt nur noch überarbeiten, weil es nur mal eben hingehackt wurde, aber die Basis ist gelegt.

Außerdem wird es einen manuell geschriebenen Tcl-Wrapper geben. Der ist zum Teil schon fertig, muss auch nur noch aufgehübscht und in sich etwas konsitenter werden. Gegenüber dem mit Swig erstellten Wrapper hat der neue den Vorteil, dass viele Funktionen in Tcl einfacher aufzurufen sind. Ich mache exzessiven Einsatz von optionalen Funktionsargumenten, Default-Werten und anderen Spielereien, die deutlich vereinfachend wirken.

Als neuesten Fortschritt kann ich heute die Überarbeitung der Audio-I/O verkünden. Die hatte es auch dringend nötig. Z. B. war es bisher so, dass man Daten erst selber in das Audio-Format umwandeln musste. Das entfällt. Außerdem sind jetzt mehr als 2 Kanäle möglich, und natürlich ist jetzt alles viel einfacher zu programmieren. Zumindest unter OpenBSD, alle anderen bleiben erstmal außen vor. Dort wird vorerst nicht weiter an der Audioausgabe gebastelt, da Portaudio tot zu sein scheint, und ich mich deshalb erst in die nativen APIs reinfuchsen muss. Alle Funktionen von esweep außer der Audio-I/O sind aber auf allen Plattformen möglich (evtl kann man mit dem Wavefile-IM-/Export einen Workaround machen).

Oh, und natürlich sind die Änderungen noch nicht online verfügbar. Vielleicht mache ich noch dieses Jahr ein neues Release.

Cpt.

Du Guter!

schade, dass ich so ein windooffauler und auch Freizeitbegrenzter bin, sonst dürfte esweep bei mir mehr, als nur auf der Platte rumzuliegen.
Unernst: Vielleicht erbarmt sich der Zausel ja doch noch?

Moin,

ich hatte darüber mit Harry schon auf der Messe gesprochen, jetzt ist Vollzug: mit esweep ist es jetzt ohne große Klimmzüge möglich, eine Entzerrung ala AudioVolver zu zaubern. Mit Vorbereitung der I/O-Puffer sind das vielleicht 50 Zeilen Quellcode in C, in Tcl dürften es etwas weniger werden.

Zumindest ist die Technik gegeben, die eigentliche Schwierigkeit besteht darin, eine vernünftige Filterfunktion zu erstellen.

Cpt.

P.S.: eigentlich war das schon vor zwei Stunden fertig, wenn ich nicht einen ganz dusseligen Fehler gemacht hätte...

P.P.S: auf meinem P4 mit 2,53 GHz geht eine FFT-Länge von 65536 bei 48 kHz Abtastrate problemlos, die nächste Stufe (131072) nicht mehr, da hat es schon Aussetzer. Für nicht optimierten Code ist das OK, wenn auch nicht überragend. Mal schauen, woran das liegt. Ich hab da so ein paar Kandidaten im Verdacht.

Moin,

diese nicht sehr beeindruckende Geschwindigkeit hat mir keine Ruhe gelassen, also habe ich ma geschaut, wo sich noch was drehen lässt.

Bei der schnellen Faltung gibt es da einen ganz klaren Kandidaten: die FFT. Davon gibt es immerhin gleich 2 pro Vorgang, und das bedeutet jede Menge komplexe Multiplikationen.

Um so eine FFT etwas schneller zu machen, gibt es 2 verschiedene Möglichkeiten:

a) man ändert die Struktur
b) man benutzt plattformabhängige Beschleunigungen.

a) habe ich jetzt mal - mehr oder weniger - erfolgreich durchgeführt. Mehr, weil ich dadurch die FFT um ungefähr den Faktor 1,5 beschleunigen konnte. Weniger, weil das (auf meinem PC) nur bis FFT-Längen bis 16384 gilt. Darüber kehrt sich der Faktor lustigerweise um. Ich vermute, dass es was mit dem Laden der Daten in den CPU-Cache zu tun hat. In der alten Struktur springt der Algorithmus nämlich sehr viel anders durch die Daten als in der neuen.

b) ist der nächste Schritt. Auf der i386-Architektur bieten sich SSE2-Befehle an. Leider ist es mit SSE2 nur schwer möglich, komplexe Multiplikationen durchzuführen. SSE3 kann das einfacher, aber das hat nicht jeder (und vor allem ich nicht).

Cpt.

Moin,

kurzes Update: die Optimierung der FFT wird nicht weiter verfolgt. Ein ganz wichtiges Designziel von esweep ist Portabilität (OK, die Audioausgabe geht demnächst nur mit OpenBSD, der Rest ist aber vollständig plattformunabhängig) und Wartbarkeit. Beides hat als Konsequenz einfachen und sauberen Code. Deshalb: kein SSE, kein Assembler oder ähnliche Schweinereien. Ich habe es versucht, aber der Gewinn rechtfertigt nicht den Aufwand.

Jetzt geht es also allein um die restlichen Verschönerungen bzw. neue Features.

Cpt.

Hi Cpt,

(OK, die Audioausgabe geht demnächst nur mit OpenBSD

Uh, keine Messsignalausgabe unter (okay, entsprechend eingerichtetes) Windows mehr in Zukunft ?

Grüße,

Alex

Moin,

so schlimm ist es nicht. Zum einen wird es irgendwann eine Audioausgabe unter Windows geben (aber nicht für v0.5), zum anderen gibt es ja immer noch die Möglichkeit, die Ausgabe über WAV-Dateien zu realisieren. In den meisten Fällen sollte das vollkommen ausreichend sein.

Cpt.

Moin zusammen,

es ist mir ja fast schon peinlich, aber über satte 2 1/2 Jahre nach dem letzten Anpacken geht es hier endlich weiter. So ist das nunmal, wenn man hart für sein Geld arbeitet. Man kommt zu nichts.

Ich habe in den letzten Wochen allerdings etwas mehr Zeit gefunden, und außerdem ist das Wetter schlechter geworden. So gibt es denn zwar kein fertiges Programm, aber dennoch mal ein Appetithäppchen:


Das ist ein Screenshot einer "kleinen" Testapplikation (ca. 1000 Zeilen im Moment, mit allem Verwaltungsschnickschnack). Impulsantwort messen und darstellen, und in dem Diagramm darunter ein ganz besonderes Gimmick: die Darstellung der Differenzkurven zu einer frei wählbaren Bezugsmessung. Sowas habe ich seit Jahren vermisst, endlich kann man mal wirklich sehen, wo sich eine Bauteiländerung auswirkt, und Winkelmessungen sind ganz einfach, ohne große Verrenkungen. Falls man dafür eine Mikrofonmatrix verwendet: jedes Mikrofon (bis zu 9) lässt sich einzeln kalibrieren (Pegel, noch nicht Frequenzgang). Die Bedienung ist ein wenig vi-like, also mit Tastenkombinationen. Trotzdem sehr einfach, und fast völlig ohne Maus (Farbänderungen muss man mausen, und es gibt ein MouseOver-Readout in den Diagrammen).

Aber was ganz wichtig für esweep ist: die Diagramme werden vom Programm selber erstellt, also kein Einsatz von gnuplot mehr (außer bei 3D-Plots). Das ist ziemlich schnell, ich weiß aber noch nicht ob es für den Echtzeit-Einsatz reicht.

Sowohl in der Bibliothek als auch in der gezeigten Applikation gibt es noch viel Kleinarbeit, also wird es bis zur Veröffentlichung noch etwas dauern. Dieses Jahr bestimmt nicht mehr. Außerdem muss noch irgendein Dummer die Anleitung schreiben, und ich befürchte sehr, dass ich das sein werde

Außerdem macht Ende des Jahres der Projekthoster Berlios dicht, ich werde mir also was neues suchen müssen. Vielleicht packe ich es auch einfach auf meinen kleinen Privatserver. Ist zwar nur DSL, aber für das geringe Aufkommen wird es reichen.

Cpt.

Moin,

Cpt._Baseballbatboy schrieb:

Aber was ganz wichtig für esweep ist: die Diagramme werden vom Programm selber erstellt, also kein Einsatz von gnuplot mehr (außer bei 3D-Plots). Das ist ziemlich schnell, ich weiß aber noch nicht ob es für den Echtzeit-Einsatz reicht.

reicht.

Kleines 2-Kanal-Oszi gebastelt, geht flüssig. Noch ohne FFT und so nen Gedöns, aber das ist erstmal egal.

Cpt.

Moin,

inzwischen habe ich auch ein Framework für IIR/FIR-Filterung im Zeitbereich drin. Inklusive Biquad-Filtergenerator (also IIRs), für FIRs habe ich keinen Generator.

Die interne Struktur beruht auf eben diesen Biquads, bei FIRs werden einfach die rekursiven Strukturen ignoriert.

Der Vorteil von IIRs gegenüber FFT-basierter Filterung (also eigentlich FIRs) ist der geringe Leistungsbedarf bei gleicher Filtersteilheit. Ausprobiert habe ich jetzt Filter mit 100 Biquads Länge, also 200. Ordnung, auf 2 Kanälen. Das macht mein Rechner hier im Leerlauf. Um die gleiche Filterordnung mit FFTs hinzubekommen muss der schon deutlich mehr schwitzen. Dafür können FIRs halt ein wenig mehr.

Cpt.

Hi Cpt.,

inzwischen habe ich auch ein Framework für IIR/FIR-Filterung im Zeitbereich drin. Inklusive Biquad-Filtergenerator (also IIRs)

Das hört sich ja intererssant an! Ist das eine Über-Alles-Entzerrung oder können Filter gerechnet werden?
Wie wird beim FIR die Zielfunktion definiert?

Gruß Pico

Moin,

Ob Über-Alles-Entzerrung oder einzelne Filterzweige, das ist völlig egal, das kann man sich nach Lust und Laune hincoden. Ich habe gestern eine 2-Kanal 3-Wege-Weiche gebaut, ohne Über-Alles (wird als Beispiel mitveröffentlicht, wenn es denn soweit ist), die hat inkl. Verwaltungscode knapp 150 Zeilen. Die Aufteilung und Filterung selber hat gerade einmal 15 Zeilen. Einen grafischen Filterdesigner will ich dazu auch noch bauen, eine Idee habe ich wie man das einfach machen könnte.

die FIR-Filter sind eher Beiwerk. Man könnte sich auch Nebenprodukt, oder Abfall nennen. Dementsprechend gibt es auch (noch) keinen Generator.

Ich sehe da aber auch nicht so den Sinn drin. FIRs spielen ihre Vorteile gegenüber IIRs erst bei hohen Filterordnungen aus, und dann lohnt sich schon der Einsatz eines FFT-basierten Algorithmus (der mit esweep auch möglich ist).

Der IIR-BiQuad-Generator kann so ziemlich jedes beliebige Filter generieren. Er kennt alle Grundtypen (Tief-/Hoch-/All-/Bandpass/-stop), mit beliebiger Güte. Filter ungerader Ordnung sind auch möglich, wenn man die Güte < 0 setzt.

Hier mal als Code-Schnippsel ein Butterworth-Tiefpass 5. Ordnung bei 1 kHz:

int samplerate = 48000; esweep_object **filter; esweep_object **tmp; /* 1. beide Biquads */ filter=esweep_createFilter("lowpass", 0.62, 1000, samplerate); tmp=esweep_createFilter("lowpass", 1.62, 1000, samplerate); /* Filter aneinanderhängen */ esweep_appendFilter(filter, tmp); /* temporären Filter wieder freigeben */ esweep_freeFilter(tmp); /* den 5. Pol erzeugen */ tmp=esweep_createFilter("lowpass", -1, 1000, samplerate); esweep_appendFilter(filter, tmp); esweep_freeFilter(tmp);

Das ist also wirklich ziemlich einfach. Wegen den Filterkoeffizienten muss man halt in ein Filterbuch schauen. Man kann Filter auch auf Festplatte speichern und wieder laden.

Cpt.

Moin,

Cpt._Baseballbatboy schrieb:

Einen grafischen Filterdesigner will ich dazu auch noch bauen, eine Idee habe ich wie man das einfach machen könnte.

so ungefähr könnte das dann aussehen:


Oben kommen Frequenzgänge rein (geladen werden Impulsantworten, die bleiben aber im Hintergrund), unten werden die Filter aufgebaut. Pro Kanal können beliebig viele Teil-Filter hintereinandergeschaltet werden (soll heißen: ich habe kein Limit eingebaut, wieviele es wirklich werden können weiß ich nicht). Die werden durch die Symbole dargestellt (z. B. das letzte im Kanal "Woofer" soll eine Linkwitz-Transformation sein). Um das ganz übersichtlich zu halten ist es möglich, Filter zu gruppieren (das erste Symbol im Kanal "Woofer" ist eine Gruppe). Irgendwelche Interaktion zwischen den einzelnen Kanälen ist nicht möglich.

Cpt.

Moin,

mal ne halbwegs gute Nachricht für alle Nicht-OpenBSDler: ich habe es heute geschafft, esweep unter Windows 7 zu kompilieren. Allerdings ohne Audio, der Rest scheint aber vollständig zu funktionieren.

Wobei ich mir jetzt nicht sicher bin, ob das nicht in irgendeinem Kompatibilitätsmodus ausgeführt wurde. Kann man das irgendwie nachprüfen?

Cpt.

Das mit den Fir-Filtern ist ziemlich simpel, da die Koeffizienten der Impulsantwort des Filters entsprechen. D.h. man gibt einen Frequenzgang vor, errechnet daraus die Impulsantwort, und die Samples sind die Koeffizienten.
Lässt sich mit dem Room EQ Wizard leicht testen, da man dort die Impulsantwort des über die EQ-Funktion eingestellten Filters als z.B. Wav exportieren kann. Das wandelt man in PCM, damit der Wav-Header verschwindet, und läd das als Koeffizientendatei in den Convolver. Fertig.

Um das ganze linearphasig zu bekommen hat KSTR mal einen Tipp gegeben: Filterkoeffizienten zeitlich invertieren, d.h. letztes Sample wird erstes, dann mit dem nichtinvertierten falten, und die Antwort ist dann linearphasig mit gleichem Frequenzgang, weil symetrisch. Habs nicht versucht, klingt für mich aber logisch.

Moin,

ja klar ist das an sich einfach, aber trotzdem müsste ich die Koeffizienten erstmal in die eigentlich Biquad-Struktur umwandeln. Da habe ich mir noch keine richtigen Gedanken drum gemacht, müsste aber auch einfach sein.

Außerdem, wie schon schrieb, fehlt mir dazu ein wenig der Antrieb. Denn wenn man FIR gewinnbringend gegenüber IIRs einsetzen will, dann werden die Filter sehr lang, und dann kann man sinnvoller gleich die schnelle Faltung mit FFTs machen.

Ich denke auch immer an die Verwendung in weniger aufwändiger Hardware. Wenn ich da eine zweikanalige 3-Wege-Frequenzweiche mit FFTs machen soll, dann müsste ein schwächerer Rechner schon ganz schön schwitzen. Das gleiche mit IIRs wäre wahrscheinlich sogar auf einem Atom-Prozessor noch gut möglich, und das sind richtige kleine Scheißteile mit wenig FP-Performance. Wenn man die Filter in einen kleinen DSP übertragen will, kommt man da sowieso nicht mehr drumherum.

Linearphasigkeit, der heilige Gral aller FIR-Fetischisten, kann man auch mit IIRs annähern. Kostet halt ein paar Allpässe, und die Generierung ist etwas kompliziert.

Cpt.

Cpt._Baseballbatboy schrieb:

Außerdem, wie schon schrieb, fehlt mir dazu ein wenig der Antrieb. Denn wenn man FIR gewinnbringend gegenüber IIRs einsetzen will, dann werden die Filter sehr lang, und dann kann man sinnvoller gleich die schnelle Faltung mit FFTs machen.

So arbeitet Brutefir für Linux:
http://www.ludd.luth.se/~torger/brutefir.html

Auch ein Atom kann locker 2x 4 Wege ohne nur im geringsten zu schwitzen, mit 64k oder 128k Taps. Läuft auch über "schnelle Faltung", soweit ich das verstanden habe.
Quellcode ist verfügbar, falls du gucken willst wie das ganze intern funktioniert.
Daneben gibts natürlich auch ne Reihe Convolver für Windows.
Vieleicht interessiert dich auch noch, wie das mit der "Raumentzerrung" funktoniert, dabei wäre dann das:

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

interessant. Vermutlich kennst du das schon, aber man weiss ja nie...

Cpt._Baseballbatboy schrieb:

Linearphasigkeit, der heilige Gral aller FIR-Fetischisten, kann man auch mit IIRs annähern. Kostet halt ein paar Allpässe, und die Generierung ist etwas kompliziert. Cpt.

Ich hab nicht wirklich Ahnung von all dem Zeug und habe gerade mal die Grundlagen durchschaut, zweifel aber trotzdem daran, das man mit IIR-Filtern und Allpässen ein ähnliches Ergebnis bekommt. Pico von HSB hat ja mal versucht "Zeitrichtigkeit" mit einer Behringer DCX (also IIR) umusetzen, was viele Diskussionen ausgelöst hat...
IIRs sind dennoch hochinteressant, weil man bei z.B. Heimkino die Latenzen der Firs gar nicht brauchen kann. Ich lese da mal interessiert mit

Es ist eigentlich schade, das du hier so wenig Resonanz hast, aber das dürfte wohl an den sehr guten Alternativen am Markt liegen, und natürlich an der BS-Auswahl

Moin,

Torsten70 schrieb:

Auch ein Atom kann locker 2x 4 Wege ohne nur im geringsten zu schwitzen, mit 64k oder 128k Taps.

ernsthaft? Ich habe das vor 2 oder 3 Jahren mal mit nem Netbook versucht, und da war bei 2 Kanälen so bei 64k Schluss. Allerdings als Ein-Block-Faltung, und nicht partitioned wie BruteFIR das macht. Außerdem war die FFT damals (und heute auch noch) nicht besonders schnell, weil zu viel overhead (der ist Absicht, das Programmziel ist mehr Universalität und Zuverlässigkeit, als Geschwindigkeit).

Cpt.

Jo,

Brutefir kommt an seine Grenzen, wenn man die Partitionen sehr klein macht. Wenn man mit den Latenzen (um 1 Sek.) leben kann, sind auch 16 oder mehr Kanäle machbar.
Mit Partitionsgrössen von 4096 (bei 64K Taps) sind bei 32 Bit 12 Faltungen gleichzeitig kein Problem, bei einem Atom 330 (Doppelkern). So lief es bei mir eine Weile.
Bei Partitionsgrössen von 1024 wirds dann kritisch, noch kleiner kostet dann richtig Leistung. 2 Kanäle wie es für die Raumentzerrung nötig ist, laufen nebenbei bei wenigen Prozent. Als FFT kommt die FFTW-Lib zum Einsatz.
Mindestlatenz ist allerdings selbst bei minimalphasigen Filtern 2x Partitionsgrösse. Bei linearphasigen die Hälfte der Filterlänge mehr...
Kannste ja mal testen.

Moin,

ich bin erstaunt. Der Atom, den ich kenne, war ne Null was FP-Arithmetik anging. Kann sein (offensichtlich), dass die das verbessert haben.

Es ist ja auch nicht so, dass meine FFT nicht noch Verbesserungspotential hat. Da geht sicherlich noch was, z. B. lassen sich Multicores ziemlich gut gewinnbringend einsetzen. Genauso lassen sich verschiedene SIMD-Techniken verwenden. Die FFTW hat ihr "wisdom", da wird AFAIK darauf eingegangen. Ob ich in der Richtung was mache, weiß ich nicht. Das widerspricht eigentlich wenigstens zwei meiner Prinzipien (plattformunabhängigkeit, geringe Komplexität).

Cpt.

Wie ich schon sagte, bin ich da (noch) nicht völlig im Bilde, was das ganze Thema angeht. So wie ich es verstanden habe, "testet" die FFTW-Bib die Prozessorerweiterungen des Systems, und erstellt dann eine Tabelle, um schneller rechnen zu können. FFTW gibt es afaik für alle BS, und afaik ist der Quellcode auch verfügbar. Ich kenne deine Ziele jetzt nicht, aber warum das Rad nochmal erfinden? Zu lernzwecken macht das natürlich sinn, aber wenn es um ein bestimmtes Ziel geht...
Der Atom 330 ist schon "recht alt". Es ist die Zwei-Kern Variante des 230, der auf dem "3.Welt Mainboard" von Intel drauf ist. Der 330 müsste 2007...2008 rausgekommen sein. Ich glaube der war auch in den ersten Netbooks drin. Solche Boards sind für 50-70€ zu haben. Gebootet hab ich anfangs vom USB-Stick, BS ist dabei Tinycore-Linux, was ca. 10 mb gross ist UND trotzdem Klickbunti bietet:

http://distro.ibiblio.org/tinycorelinux/welcome.html

Noch schmaler gehts wohl nur bei Embedded-Systemen.

Moin,

ja, die FFTW prüft das System und entscheidet dann, welchen FFT-Algorithmus sie verwendet. Das wird nur einmal gemacht und abgespeichert, weil das prüfen ziemlich lange dauert.

Neben dem Lerneffekt, den ich mir durch die eigene FFT erhoffe, gibt es mit der FFTW noch ein ganz wichtiges Problem: sie steht unter der GPL, und wenn ich die nutzen wollte, müsste mein ganzes Projekt auch unter der GPL stehen. Ich benutze aber die BSD-/MIT-Lizenz. Das funktioniert nicht zusammen.

Cpt.

Ok. Es ist aber doch schonmal was, wenn man weiss das es grundsätzlich möglich ist
Es gibt btw. ne ganze Menge Leute die Brutefir gerne nutzen (würden), aber an Linux selbst verzweifeln. Für eine hohe Verbreitung und viel Interesse ist selbst Linux noch "zu abgefahren".

Die IIR Sache bleibt trotz allem interessant, vor allem weil ich auch ein wenig interesse daran habe, den ganzen "Quark" zu checken. Kann ja nicht schaden wenn man halbwegs weiss was man da tut.

Moin,

Torsten70 schrieb:

IIRs sind dennoch hochinteressant, weil man bei z.B. Heimkino die Latenzen der Firs gar nicht brauchen kann. Ich lese da mal interessiert mit

hier muss man mal kurz drauf eingehen: wenn man PC-basiert filtert, hat man immer 2 zusätzliche Latenzen, nämlich der Ein- und Ausgabepuffer der Soundkarte/des Treibers. Die Struktur ist so:

Eingabepuffer -> Filter -> Ausgabepuffer

Ich konnte bei mir die Puffergrößen auf 5 ms @ 48 kHz pro Puffer senken, also insgesamt 10 ms Latenz. Mit dieser Größenordnung muss man auch bei IIRs leben.

Cpt.

Hi,

10ms sind 3,4 Meter Abstand zur Schallquelle. Beim Fernsegucken hab ich das auch, und hatte ich bisher kein Problem damit Klar, die kommen oben drauf, aber damit muss man wohl leben.

Torsten

Moin,

ja, es ist kein Drama. Üblicherweise öffnet OpenBSD die Soundkarte aber mit 50 ms Latenz. Das ist ein sicherer Wert, damit die Audioausgabe auch unter widrigen Bedingungen sauber bleibt.

Der Crossovergenerator ist im übrigen fast fertig, und sieht so aus:



In dem Bild sieht man jetzt nur einen Kanal, das Programm wird hier nur als EQ missbraucht. Die Kurve zeigt die Filterfunktion an sich, man kann genauso gut auch einen "echten" Frequenzgang laden.

Die drei Blöcke unten sind gruppierte Filter, d. h. da sind mehrere Filter zu einem zusammengefasst, um die Übersichtlichkeit zu erhöhen. Man kann Filter/Gruppen auch unterdrücken, das Ergebnis wird dann live oben angezeigt. Probehören ist auch möglich.

Cpt.

Moin,

ich habe in den letzten Wochen ein wenig mit Portaudio gespielt, und es tatsächlich geschafft, ein Interface dafür zu basteln. esweep kompilierte und lief ja sowieso schon unter Windows, jetzt auch mit Audio. Getestet auf Windows XP 32 Bit (mit WinMM) und Windows 7 32 Bit (WinMM und WASAPI). Portaudio unterstützt auch MacOS und Linux, das habe ich aber noch nicht getestet.

Mir gefallen einige Sachen aber noch nicht, insbesondere die Beispiele und Tcl-Skripte laufen teilweise noch nicht richtig, die muss ich noch überarbeiten. Außerdem ist das Verhalten der beiden Audio-Interfaces (OpenBSD nativ / Portaudio) etwas unterschiedlich, das soll nicht sein. Deshalb sind die Sourcen immer noch nicht online.

Wer aber Interesse hat, hier ist ein Archiv verfügbar: http://fabricius.dyndns.info/docs/esweep_snapshot20120415.tar.gz . Für eine erfolgreiche Kompilierung braucht es:
- einen GCC (unter Windows: MinGW/MSYS)
- eine Tcl-Distribution (Version 8.5, unter Windows installiert in C:\Tcl)
- die Portaudio-Sourcen (müssen in ein Unterverzeichnis von esweep kopiert werden).

Cpt.

Moin,

ich habe den Quellcode bei Berlios ins CVS gepackt. Wer Interesse hat, kann davon einen Checkout machen. Dazu müsst ihr den anonymen Weg nehmen:

cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/esweep login
cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/esweep co esweep

Windows-Nutzer brauchen natürlich ein CVS-Programm dazu, bei Berlios gibt es dazu eine Anleitung:
http://developer.ber...?docid=35&group_id=2

Zu den Vorraussetzungen unter Windows schaut bitte in den vorherigen Post. Ich kann auch eine vorkompilierte Portaudio-DLL bereitstellen. Für Linux und MacOS gilt prinzipiell das gleiche, allerdings dürfte da ein GCC schon installiert sein.

Die Tcl-Beispiele sind teilweise funktionstüchtig, die in C gar nicht. Leider fehlen dazu noch Anleitungen. Da steht man dann also teilweise wie der Ochs vorm Berg. Tipp: bei "impulse" kann man die Messung durch die Taste 'm' starten.

Cpt.