Gehe zu Seite: |vorherige| Erste 2 3 4 Letzte

Entwicklung eines freien LS-Messprogramms

+A -A
Autor
Beitrag
Cpt._Baseballbatboy
Inventar
#201 erstellt: 30. Aug 2007, 15:54
Moin,

inzwischen sind alle geplanten Funktionen implementiert, das heißt es gibt jetzt auch eine Funktion zur Berechnung von C(B)SD. Beim CBSD wundert mich allerdings noch die Skalierung. Das das Ergebnis irgendwie mit der Länge der verwendeten FFT skaliert war zu erwarten. Aber irgendwie passt das noch nicht. Mal sehen woran das hakt.

Die C(B)SD-Funktionen erzeugen den Datentyp "Surface" ("Oberfläche"). Das ist ein dreidimensionales Objekt, bei dem zu jedem X-Y-Koordinatenpaar ein Z-Wert gehört. Auch auf diesen Datentyp kann man viele (nicht alle) mathematischen Funktionen anwenden. Ich habe diesen Datentyp absichtlich kreiert, um einfach Wasserfälle oder Spectrogramme darstellen zu können. Directivity-Messungen (bzw. die Darstellung) werden dadurch vereinfacht, das Vorgehen ist ungefähr so:

- "Surface" mit ausreichend Platz erzeugen (Funktion vorhanden)
- Frequenzgang messen
- Ergebnis zu "Surface" hinzufügen, mit der X- als Frequenzachse- der Messwinkel wird als einzelner y-Wert gespeichert
- mit dem nächsten Winkel weitermachen

Das wird wirklich ein Kinderspiel.

Jetzt noch Doku schreiben und fertig is das.

Gruß
Cpt.
Cpt._Baseballbatboy
Inventar
#202 erstellt: 31. Aug 2007, 17:24
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.


[Beitrag von Cpt._Baseballbatboy am 31. Aug 2007, 18:20 bearbeitet]
c2007
Stammgast
#203 erstellt: 05. Sep 2007, 18:02
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.
Cpt._Baseballbatboy
Inventar
#204 erstellt: 05. Sep 2007, 20:30
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.
Cpt._Baseballbatboy
Inventar
#205 erstellt: 07. Sep 2007, 13:09
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.


[Beitrag von Cpt._Baseballbatboy am 08. Sep 2007, 11:39 bearbeitet]
Cpt._Baseballbatboy
Inventar
#206 erstellt: 07. Sep 2007, 15:28
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.


[Beitrag von Cpt._Baseballbatboy am 07. Sep 2007, 20:49 bearbeitet]
c2007
Stammgast
#207 erstellt: 09. Sep 2007, 20:44
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
Cpt._Baseballbatboy
Inventar
#208 erstellt: 09. Sep 2007, 21:02
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.
Cpt._Baseballbatboy
Inventar
#209 erstellt: 10. Sep 2007, 09:42
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.
eltipo
Inventar
#210 erstellt: 10. Sep 2007, 16:03
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...
Granuba
Inventar
#235 erstellt: 09. Nov 2007, 01:22
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"
Cpt._Baseballbatboy
Inventar
#236 erstellt: 28. Jul 2008, 20:55
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.
Granuba
Inventar
#237 erstellt: 30. Jul 2008, 22:23
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
Karlyzo
Ist häufiger hier
#238 erstellt: 07. Sep 2008, 11:02
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.


[Beitrag von Karlyzo am 07. Sep 2008, 11:09 bearbeitet]
Karlyzo
Ist häufiger hier
#239 erstellt: 07. Sep 2008, 12:46
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?
Cpt._Baseballbatboy
Inventar
#240 erstellt: 08. Sep 2008, 17:49
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.
Karlyzo
Ist häufiger hier
#241 erstellt: 08. Sep 2008, 18:34
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
Cpt._Baseballbatboy
Inventar
#242 erstellt: 20. Sep 2008, 12:07
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.
Cpt._Baseballbatboy
Inventar
#243 erstellt: 14. Nov 2009, 16:55
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.
tiki
Inventar
#244 erstellt: 15. Nov 2009, 13:15
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?
Cpt._Baseballbatboy
Inventar
#245 erstellt: 25. Nov 2009, 00:55
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.


[Beitrag von Cpt._Baseballbatboy am 25. Nov 2009, 19:54 bearbeitet]
Cpt._Baseballbatboy
Inventar
#246 erstellt: 01. Dez 2009, 19:40
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.
Cpt._Baseballbatboy
Inventar
#247 erstellt: 08. Jan 2010, 22:54
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.
castorpollux
Inventar
#248 erstellt: 13. Jan 2010, 16:16
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
Cpt._Baseballbatboy
Inventar
#249 erstellt: 14. Jan 2010, 21:02
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.
Cpt._Baseballbatboy
Inventar
#250 erstellt: 13. Okt 2011, 20:17
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:
esweep v0.5 impulse.tcl

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.
Cpt._Baseballbatboy
Inventar
#251 erstellt: 18. Okt 2011, 19:31
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.
Cpt._Baseballbatboy
Inventar
#252 erstellt: 19. Nov 2011, 18:06
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.
HiFi-Selbstbau
Inventar
#253 erstellt: 21. Nov 2011, 10:01
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
Cpt._Baseballbatboy
Inventar
#254 erstellt: 21. Nov 2011, 21:00
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.
Cpt._Baseballbatboy
Inventar
#255 erstellt: 28. Nov 2011, 22:32
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:
Draft GUI of esweep xover designer

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.
Cpt._Baseballbatboy
Inventar
#256 erstellt: 30. Nov 2011, 19:01
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.
Torsten70
Inventar
#257 erstellt: 30. Nov 2011, 19:24
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.
Cpt._Baseballbatboy
Inventar
#258 erstellt: 30. Nov 2011, 22:34
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.
Torsten70
Inventar
#259 erstellt: 01. Dez 2011, 07:32

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
Cpt._Baseballbatboy
Inventar
#260 erstellt: 01. Dez 2011, 18:58
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.
Torsten70
Inventar
#261 erstellt: 01. Dez 2011, 19:23
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.
Cpt._Baseballbatboy
Inventar
#262 erstellt: 01. Dez 2011, 22:16
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.
Torsten70
Inventar
#263 erstellt: 01. Dez 2011, 22:33
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.
Cpt._Baseballbatboy
Inventar
#264 erstellt: 02. Dez 2011, 07:05
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.
Torsten70
Inventar
#265 erstellt: 02. Dez 2011, 08:05
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.
Cpt._Baseballbatboy
Inventar
#266 erstellt: 28. Jan 2012, 11:41
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.
Torsten70
Inventar
#267 erstellt: 28. Jan 2012, 12:00
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
Cpt._Baseballbatboy
Inventar
#268 erstellt: 29. Jan 2012, 14:41
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:

Xover generator

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.
Cpt._Baseballbatboy
Inventar
#269 erstellt: 15. Apr 2012, 07:43
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.
Cpt._Baseballbatboy
Inventar
#270 erstellt: 29. Sep 2012, 16:55
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.
mbrennwa
Neuling
#271 erstellt: 09. Jan 2015, 09:15
Das ist ein alter Thread, finde ich aber SEHR interessant, weil open source und Plattformübergreifend. Ich versuche zur Zeit, die Farina-Methode in meine Messsoftware zu implementieren (MATAA, http://audioroot.net/mataa-mats-audio-analyzer ). Die Original-Publikation von A. Farina ist stellenweise leider etwas ungenau und beschreibt die Methode nur mit Figuren und (unpräzisem) Text. Jedenfalls ist die Farina-Beschreibung ungenügend, um die Methode vollständig zu implementieren.

Die Idee zu den ATB-Wasserfallspektren ist auch super, die werde ich mir bei Gelegenheit ebenfalls näher ansehen.

Darum würde mich der esweep Code zur Farina-Methode (und ev. dem ATB-Wasserfall) sehr interessieren. Leider scheint esweep bei berlios.de nicht mehr verfügbar zu sein. Kann mir jemand weiterhelfen?
Suche:
Gehe zu Seite: |vorherige| Erste 2 3 4 Letzte
Das könnte Dich auch interessieren:
Fragen zu esweep, dem freien LS-Messprogramm
Granuba am 07.11.2007  –  Letzte Antwort am 21.04.2008  –  32 Beiträge
Frequenzgang Lautsprecher - Spannung am LS
betocool77 am 28.03.2012  –  Letzte Antwort am 28.03.2012  –  2 Beiträge
LS Simulationsprogramm
sandscholle am 30.01.2014  –  Letzte Antwort am 30.01.2014  –  2 Beiträge
Hat ARTA eines Sinusgenerator.
Velocifero am 15.03.2009  –  Letzte Antwort am 16.03.2009  –  5 Beiträge
"Momentanverbrauch" eines Lautsprechers messen
losloco am 15.03.2013  –  Letzte Antwort am 26.03.2013  –  35 Beiträge
Dreheinrichtung für LS-Messungen
AC-SB am 24.08.2010  –  Letzte Antwort am 13.10.2010  –  16 Beiträge
Kompaktes LS mess-system
_hyperi_on_ am 06.01.2013  –  Letzte Antwort am 10.01.2013  –  3 Beiträge
LS Messsystem + Simi-Software
sandscholle am 07.07.2013  –  Letzte Antwort am 07.07.2013  –  2 Beiträge
LS-Messdiagramme - Buckel
Anro1 am 03.09.2014  –  Letzte Antwort am 03.09.2014  –  32 Beiträge
Die Frequenz eines Chassis per Spule trennen
Odessa_HP am 06.05.2017  –  Letzte Antwort am 06.05.2017  –  9 Beiträge

Anzeige

Aktuelle Aktion

Partner Widget schließen

  • beyerdynamic Logo
  • DALI Logo
  • SAMSUNG Logo
  • TCL Logo

Forumsstatistik Widget schließen

  • Registrierte Mitglieder829.132 ( Heute: 55 )
  • Neuestes MitgliedSoundMensch
  • Gesamtzahl an Themen1.386.882
  • Gesamtzahl an Beiträgen18.414.812

Hersteller in diesem Thread Widget schließen