Entwicklung eines freien LS-Messprogramms

Ich habe hier zwei Beispielmessungen, einmal war 100Hz, das andere mal 200Hz die konstante Frequenz*

100Hz:



200Hz:



Allerdings muss ich sagen, dass die Werte ziemlich hoch sind. Ich halte mich mal noch zurück, was die Exaktheit angeht.

Gruß
Cpt.

* noch ein paar Worte zur Messmethode. Statt einem logarithmischen kommt ein linearer Sweep zum Einsatz, der mit einem weiteren Ton konstanter Frequenz überlagert ist. Der Sweep ist dabei um -3dB zurückgenommen. Ansonsten ist die Idee die gleiche wie bei den logarithmischen Sweeps.

Hallo Zappadeus,
jetze würd es langsam ünteressant!
Was meinste mit Sweep um -3dB zurückgenommen? Das Pegelverhältnis f1/f2, wobei f2=fsweep? Das sollte man frei wählen können, zumindest 0dB, -3dB, -6dB (2:1), -12dB (4:1, angelehnt an DIN-EN-20286). Zusätzlich ist f1 schon frei wählbar, nicht wahr?
Was heißt IMD1/IMD2? Die Summe der entsprechenden Nebenkeulen drunter und drüber? Um die anderen zu sehen und was obenrum noch so rumfleucht sind dann aber doch eher statische Messungen interessant, oder?
Sehr schön, eins rauf mit Mappe!
Pleib fleißich, Pube!

Moin

tiki schrieb:

Was meinste mit Sweep um -3dB zurückgenommen? Das Pegelverhältnis f1/f2, wobei f2=fsweep?

Ja, genau. Dabei kann der Sweep noch ein beliebiges Spektrum annehmen (theoretisch, ich muss das nur noch dem User zugänglich machen).

Das sollte man frei wählen können, zumindest 0dB, -3dB, -6dB (2:1), -12dB (4:1, angelehnt an DIN-EN-20286).

Das ist kein Problem.

Zusätzlich ist f1 schon frei wählbar, nicht wahr?

Jenau. Was ich nicht bedacht habe, ist die Verschiebung der Spektren der IM-Produkte. Die sind im Diagramm nämlich genau um f1 nach oben versetzt. Das muss ich noch anpassen.

Was heißt IMD1/IMD2? Die Summe der entsprechenden Nebenkeulen drunter und drüber?

Der Index entspricht der Ordnung. IMD0 ist die Grundwelle (ganz offensichtlich), IMD1 ist f2+1*f1, IMD2 f2+2*f1 usw.

Was man nicht sieht, sind die Nebenspektren von z. B. 2*f2+f1, also die Produkte um die Harmonischen von f2 herum. Die Harmonischen von f1 sind schon enthalten.

Ich halte mich auch weiterhin noch zurück, was die Korrektheit des Ergebnisses angeht. Vor allem der Einfluss des überlagerten Sinus ist mir noch nicht ganz klar. Mich wundern vor allem die hohen Werte. Entweder, ich bin halb taub (was ich nicht ausschließen möchte), oder man hört das einfach nicht. Und ich kann keine richtige Korrelation zwischen Klirr und IMD erkennen. Da müssen noch ein paar gezielte Untersuchungen vorgenommen werden. Z. B. wenn eine Harmonische von f1 genau auf einer Klirrspitze liegt.

Um die anderen zu sehen und was obenrum noch so rumfleucht sind dann aber doch eher statische Messungen interessant, oder?

Ja, definitiv. Dazu werde ich auch noch eine Multisinusmessung einbauen, also nicht nur Zweiton, sondern richtig viele. So grob 100 einzelne Töne. Wenn man die gleichzeitig abspielt ergibt sich ein wunderbares Bild von dem, was die Tröte wirklich von sich gibt.

Diese Messungen dauern übrigens auf meinem Rechner keine 20 Sek. (ich muss die exakte Zeit wirklich mal stoppen). Die dauern länger als die Klirrmessungen, weil der Sweep länger sein muss, sonst geraten die IRs der IM-Produkte in die IR der Grundwelle.

Gruß
Cpt.

P.S:
habe noch eine Loopback-Messung gemacht um zu zeigen, dass da wirklich etwas gemessen wird:



P.P.S.: eine Vegleichsmessung mit ARTA (Zweitonanregung mit 100Hz und 1kHz, gleiches Amplitudenverhältnis) ergibt bei mir tatsächlich um 6dB zu hohe Werte. Erstaunlicherweise ist das immer so. Das ist doch sehr verdächtig...

Herzlichen Dank, keine weiteren Fragen vorerst.
Aber es gefällt mir immer besser. Kann es auch sicher bald probieren, die Hardware läuft, ein 25-Euro-Firewireadapter reicht für die Messungen mit meiner ext. Soundkarte offenbar.

Diese IMD-Messung wird vorerst nicht eingebaut. Zu viele Einschränkungen, und die Interpretation ist schwierig.

Stattdessen werde ich eine Funktion einbauen, die mir die IMD für beliebige Mehrtonanregung aus den gemessenen Klirrkomponenten errechnet.

Gruß
Cpt.

In Kürze wird es eine neue Version geben. Die beinhaltet einige Änderungen, was die Bedienung angeht. Die ist jetzt noch mehr auf Skriptsteuerung ausgerichtet, und sehr viel flexibler.

Es gibt nur noch eine Binärdatei, nicht mehr 4 verschiedene. Die Funktionalität wurde gebündelt. Und es sind ein paar Funktionen hinzugekommen. Diese "Module" werden folgendermaßen aufgerufen:

esweep "Modul" <Optionen>

Die Module im Einzelnen:

generate:
generiert ein Anregungssignal. Aktuell habe ich nur einen logarithmischen Sweep implementiert, es werden aber noch weitere Signale hinzukommen, wie Einzel-/Multisinus, Rauschen (verschiedener Färbung), lineare Sweeps, usw.
Wenigstens der Einzelsinus wird in der anstehenden Version möglich sein, weil er für die Kalibrierung notwendig ist.

play:
spielt das von "generate" erzeugte Signal ab. Dieses Modul ist zum Einpegeln der ganzen Messkette gedacht und spielt bei der Kalibrierung eine wichtige Rolle.

measure:
tut nichts anderes als messen. Das aufgenommene Signal wird in einer Datei abgespeichert. Die darin enthaltenen Werte können skaliert werden. Wozu das gut ist, werde ich später erläutern.

deconvolve:
erzeugt aus dem gemessenen Signal und dem Anregungssignal eine Impulsantwort.

ir:
extrahiert aus der sehr langen Impulsantwort von "deconvolve" kurze Sequenzen. Meistens die von K1, wenn ein logarithmischer Sweep benutzt wurde auch die von Klirrfaktoren höherer Ordnung.

fft:
berechnet die FFT eines Signals. Egal ob Impulsantwort oder Anregungssignal. Ausgabe ist entweder komplex (Real- und Imaginärteil) oder polar (Amplitude und Phase). Kann gleichzeitig glätten und, wenn es sich um Impulsantworten von Oberwellen handelt, das Ergebnis stauchen (wie in den bisherigen Versionen auch). Gefenstert wird hier übrigens auch, ziemlich flexibel, verschiedene Fensterarten mit beliebigen Breiten.

csd:
berechnet den Wasserfall aus einer Impulsantwort. Funktionen ähnlich wie in "fft".

2db:
wandelt polare Daten in Dezibel um. Der Bezugswert wird als Option übergeben.

raw2ascii:
Zwischen den einzelnen Modulen werden Binärdateien ausgetauscht. Das ist schneller und platzsparender. Dieses Modul wandelt die Daten in ASCII-Textdateien um, die von z. B. gnuplot gelesen werden können.

Das nur mal als grober Überblick. Kommentare erwünscht.

Ich verrate noch schnell, wie die Kalibrierung (nicht Kompensation!) vor sich geht:

zuerst spielt man mit "play" einen kontinuierlichen Sinuston ab ("play" bietet dafür eine Option) und misst die Ausgangsspannung der Soundkarte (Abbruch mit STRG+C). Man braucht den Spitzenwert, also muss ein RMS-Wert umgerechnet werden (na, welcher Faktor ist das?). Diesen Wert merken (Bleistift und Papier eignen sich sehr gut dafür).

Es folgt eine Loopback-Messung, also Ein- und Ausgang der Soundkarte direkt miteinander verbinden. Dann mit "measure" die Kalibirier-Messung durchführen, als Anregungssignal nimmt ebenfalls wieder den Sinus (es geht auch ein Sweep, Hauptsache irgendwas sinusförmiges). "measure" gibt dann einen Faktor zurück. Multipliziert man die gemessene Ausgangsspannung mit diesem Faktor, erhält man die maximale Eingangsspannung. Diese merken.

Mit dieser Spannung, der Empfindlichkeit des Mikrofons und dem Verstärkung des Mikrovorverstärkers lässt sich dann ein weiterer Faktor berechnen, der in Zukunft zur Skalierung im Modul "measure" verwendet werden kann.

Eine genaue Anleitung ist in Arbeit und wird dann auf der Webseite des Projektes veröffentlicht.

Gruß
Cpt.

Na super. Wie es aussieht hats meinen Mikrofonverstärker zerlegt. Klasse. Da ist doch der ganze Tag im Arsch.



Gruß
Cpt.

Er hat einen Wackler am Line-Ausgang. Das dürfte zu beheben sein.

Nichtsdestotrotz habe ich eine auf Perioden normierte Darstellung des Wasserfalls gebastelt:



Der Frequenzgang sieht wegen dem Wackler komisch aus. Den kann ich fast beliebig verändern, wenn ich am Stecker rumhantiere

Wie man sieht, ist im Bass eigentlich alles in Ordnung, schnelles und sauberes Ausschwingen. Aber im Hochton wirds doch ziemlich langsam. Und jetzt überlegt Euch mal, da oben wär noch ne fette Membranresonanz.

Ganz nebenbei ist in der neuen Version die Audioausgabe unter Windows und Linux hinüber. Ich habe keine Ahnung, warum, deshalb wird sich die Veröffentlichung noch etwas hinziehen.

Gruß
Cpt.

Mein Mikrofonverstärker funktioniert wieder.

Der Fehler in der Audioausgabe unter Linux und Windows ist beseitigt.

Kurz: die neue Version 0.2 steht zum Download bereit.

Und zwar hier ganz offiziell: https://developer.berlios.de/project/showfiles.php?group_id=7162

Und hier ganz inoffiziell: ftp://fabricius.homeip.net/pub/esweep

Die Zip-Datei enthält eine ausführbare Datei für Windows. Die andere, mit der Endung tar.gz, enthält den Quellcode, zusammen mit Makefiles für OpenBSD und Linux und ein paar leidlich kommentierten Beispielskripten.

Eine Anleitung wird noch geschrieben und steht demnächst unter http://esweep.berlios.de zur Verfügung.

Gruß
Cpt.

Es existiert jetzt endlich eine Webseite unter http://esweep.berlios.de

Der Link "Anleitung" führt zu einer fast vollständigen Beschreibung des Programms (was fehlt ist zur Benutzung nicht weiter wichtig - hoffe ich).

Viel Spaß.

Gruß
Cpt.

Inzwischen gibt es auch eine kleine Application Note zum Thema Kalibrierung: http://esweep.berlios.de/appnotes/an01.html

Gruß
Cpt.

Es lohnt sich weiterhin, die Webseite zu besuchen. Denn heute habe ich eine Application Note veröffentlicht, die eine einfache Messung des Frequenzganges eines Lautsprechers beschreibt: http://esweep.berlios.de/appnotes/an02.html

Gruß
Cpt.

Ahh, ohh,
der Fleißige war wieder an der Arbeit. Sehr schön, danke!

Geschützter Hinweis (zum Lesen markieren): Und ich hab es immer noch nicht probiert.

Es sind jetzt auch ein paar ordentliche Beispielskripte verfügbar: http://esweep.berlios.de/scripts.html

Es sind aber wirklich nur Beispielskripte. Die letzten beiden in Kombination sind aber auf jeden Fall schonmal ein Anfang, um sich ernsthaft mit dem Programm auseinanderzusetzen.

Gruß
Cpt.

Wie ich hier schonmal andeutungsweise erwähnte, habe ich mir eine Möglichkeit überlegt, wie man die Technik des ATB Wasserfalls ein wenig eleganter gestalten kann.

Erstmal: was tut ATB eigentlich?

ATB nutzt einen gefensterten (oder modulierten, die genaue Erzeugung ist mir unbekannt, ist aber auch egal) Sinusburst von wenigen Perioden, spielt diesen über den Lautsprecher ab und nimmt ihn dann natürlich auf. Es wird dann die Hüllkurve der Antwort errechnet und durch ein paar Umformungen erhält man dann den bekannten ATB Wasserfall, wie ihn die K&T verwendet. Natürlich muss man dazu jede Menge Sinusbursts bei unterschiedlichen Frequenzen verwenden. Dieses Verfahren hat ein paar Vorteile, aber auch Nachteile, auf die ich noch eingehen werde.

Zuerst aber ein paar Bilder. Der Sinueburst sieht in etwa so aus (S. Linkwitz macht es ganz ähnlich, deswegen bediene ich mich bei ihm): http://www.linkwitzlab.com/images/photos/b-3klin.gif

Und so sieht dann die errechnet Hüllkurve aus, netterweise auch sehr passend kommentiert: http://www.linkwitzlab.com/images/photos/b-3k-500.gif

Warum ist diese Technik nun überlegen?

1.) der klassische Wasserfall lässt sich in seiner Form sehr stark die Art der Fensterung (sowohl am Ende der ausgewerteten Impulsantwort als auch durch die Länge der rise time) beeinflussen. Eine Fensterung findet bei der Burst-Methode nicht statt, weil keine FFT durchgeführt wird, somit kein Fenster gesetzt werden muss (aus hoffentlich bekannten Gründen)

2.) die klassische Version geht vom eingeschwungenen Zustand (unendlich langer gespielter Sinuston) aus und berechnet dann das Spektrum nachdem der Sinus abgeschaltet wurde. Weil dieser Abschaltvorgang ein sehr breites Spektrum beinhaltet, verschmiert der Wasserfall das gesamte Spektrum, die Frequenzauflösung leidet. Den gleichen Effekt sieht man auch, wenn man statt eines gefensterten Bursts einen ungefensterten verwendet.
In der Burst-Methode gibt es keine Ein- und Abschaltvorgänge (wegen der Fensterung), folglich findet auch keine Verschmierung (tatsächlich schon, eben durch die Fensterung, aber sehr viel geringer) statt.

3.) Raumreflexionen lassen sich mit dem klassichen Wasserfall nicht eindeutig bestimmen, höchstens erahnen. Die Burst-Methode erlaubt es, diese genau zu erkennen (wie ich noch zeigen werde).

4.) aus der Burst-Methode lässt sich sehr leicht eine auf Perioden normierte Darstellung ermitteln.

Leider ist diese Burst-Methode ziemlich langsam. Schließlich muss jede einzelne Frequenz gemessen und ausgewertet werden. Wenn man eine ordentliche Frequenzauflösung haben will, dann dauerts eben. Außerdem können durch Raumreflektionen Verdeckungseffekte auftreten.

Und hier setzt meine Lösung an. Normalerweise misst man bei einem Lautsprecher immer die Impulsantwort, schließlich erhält man daraus den Frequenzgang und auch den klassischen Wasserfall. Diese Impulsantwort hat eine sehr bemerkenswerte Eigenschaft: sie beschreibt ein sogenanntes LTI-System (Linear Time Invariant, also ohne Verzerrungen und es verändert seine Eigenschaften nicht mit der Zeit) vollständig.

Daraus folgt, dass es eine Möglichkeit geben muss, die Antwort des Systems - in unserem Fall wohl meist ein Lautsprecher - auf ein beliebiges Signal zu errechnen. Und das geht mit der sogenannten Faltung. Es gibt auch eine sehr schnelle Methode, die zu errechnen, mit Hilfe zweier FFTs, komplexer Multiplikation und einer inversen FFT. Diese Methode wende ich hier an (und nicht nur bei dieser Berechnung).

Ich habe mir also gedacht, statt zeitaufwändig jede einzelne Frequenz mit einem Burst zu messen, errechne ich das einfach. Ich erzeuge mir also im Speicher des Rechners einen solchen Burst, falte ihn mit der Impulsantwort und mache dann genau die gleichen Umformungen wie ATB auch.

Gesagt, getan. Und so sieht das ganze dann aus:

Periodische Darstellung, Impulsantwort war 4,5ms lang. Frequenzauflösung 1/6 Oktave (nicht geglättet, sondern tatsächlich berechnet!), Zeitauflösung 6 Schritte pro Periode. Man erkennt sehr gut die kleine Resonanz um 5kHz (die die Weiche nicht ganz wegbekommt).



Und nun das ganz in zeit-linearer Darstellung, Zeitauflösung 0.1ms. Wie man sieht, sieht man nichts.



Die zeitlineare Darstellung ist nicht so schön aussagekräftig, ich vermute mal, sie wird sich nicht durchsetzen. Bleibt dann halt der Vollständigkeit wegen drin.

So sieht das im übrigen aus, wenn Raumreflexionen eingefangen werden. Impulsantwort ist nun 10mslang, ansonsten alles wie gehabt. Dieser eine Kamm, der sich in einer Kurve einem entgegenstreckt, das ist eine Raumreflektion nach ~5ms. Man kann sich gut vorstellen, dass die in der Lage ist, Membranresonanzen zu verdecken. Immerhin schrammt die nur knapp an der bekannten 5kHz-Resonanz entlang.



Und hier das ganze in zeitlinearer Darstellung, ein wenig gedreht, und man kann diese Reflektion bei 5ms eindeutig erkennen.



Und wie lange dauert das nun? Ich habs nicht messen können, ich habe den Befehl eingegeben, Enter gedrückt und das Ergebnis da. Natürlich lag die Impulsantwort schon vor. Deren Messung dauert aber auch gerade mal 5 Sekunden auf modernen PCs, der Geschwindigkeitsvorteil liegt also klar auf meiner Seite.

Diese Wasserfall-Methode wird in der nächsten Version verfügbar sein, also dass mir keiner auf die Idee kommt, jetzt gerade deswegen die aktuelle Version 0.2 herunterzuladen. Dafür gibts andere Gründe (z. B. dass die wirklich spitze ist ).

Gruß
Cpt.

Das Bildchen mit K1 und K3 als CSD in einem Diagramm ist doch noch jedem in Erinnerung, ja? Nun, mit der neuen Methode schaut das so aus:



Nun, man kann ja schon ein wenig erahnen, wie der Hase läuft.

Wenn man sich nun das ganze von der Seite anschaut, dann sieht man furchtbares: selbst nach 20 (!) Perioden ist der K3 erst auf -25dB abgefallen. Und nein, das ist keine Reflexion, die hab ich ausgeblendet. Aus dem ersten Bild kann man gut erkennen, dass K1 da schon weit unter -40dB ist.



Edit:
von wegen, keine Reflexion. Natürlich mischt sich da eine mit ein, deswegen dieser entgegenkommende Bogen und die Buckel in der Seitenansicht. Das ist die berühmte frühe Reflexion an meinem Mikrofonständer. Womit man wieder sieht, dass man vernünftige Messbedingungen braucht, um keinen Mist zu messen.

Gruß
Cpt.

Ich habe ein Datenfile zusammen mit einer Steuerungsdatei für gnuplot hochgeladen.

Hier die Daten: http://esweep.berlios.de/csd.txt
Und die Steuerungsdatei: http://esweep.berlios.de/csd.plt

Ruft man gnuplot mit (auf den Strich achten!)


gnuplot csd.plt -


auf so zeigt sich sofort eine drehbare Ansicht dieser Daten mit angemessener Skalierung. Natürlich kann man an der was ändern, wenn man will.

Das Bild zeigt einen auf Perioden normierten Wasserfall, Frequenzauflösung 1/6 Oktave, 20 Perioden mit 6 Abtastwerten pro Periode. Das ist eine ziemlich hohe Auflösung, wie man sieht.

Noch ein Wort zu der Frequenzauflösung: die ausgewerteten Frequenzen werden dynamisch berechnet, und zwar in Abhängigkeit von der Länge der Impulsantwort. Die niedrigste Frequenz entspricht dem Kehrwert der Länge, darunter liegende Frequenzen sind eh nicht genau berechenbar (man erinnere sich an die Unschärferelation).

Gruß
Cpt.

Original geschrieben von mir selber Diese Wasserfall-Methode wird in der nächsten Version verfügbar sein, also dass mir keiner auf die Idee kommt, jetzt gerade deswegen die aktuelle Version 0.2 herunterzuladen. Dafür gibts andere Gründe (z. B. dass die wirklich spitze ist ).

Es besteht ja immer noch die Möglichkeit, sich den aktuellen Stand der Dinge aus dem CVS zu ziehen. Wie das geht, ist z. B. hier beschrieben. Macht aber nur Sinn, wenn man zufällig Linux oder ein BSD-Derivat (also auch MacOS) benutzt. Das Programm unter Windows zu kompilieren ist etwas komplizierter.

Wenn man das macht dann erhält man so schöne Features wie den neuen Wasserfall, oder ganz brandaktuell, Rauschen unterschiedlichster Färbung als Messsignal. Wer allerdings _jetzt_ auf die Idee kommt um sich _jetzt_ den Quellcode zu organisieren, dem sei gesagt, dass die Technik mit den logarithmischen Sweeps _heute_Abend_ nicht funktionieren wird, weil zwei wichtige Module fehlen*. Außerdem hat sich in den Programmaufrufen etwas geändert, und die Anleitung auf der Webseite ist für die Version im CVS nicht mehr gültig.

Ich habe mir eine ToDo-Liste erstellt, da sind noch 6 Punkte drauf abzuarbeiten (inkl. der beiden fehlenden Module). Inkl. der neuen Doku sollte ich noch diesen Monat damit fertig werden.

Gruß
Cpt.

* dieses Manko ist ab sofort behoben

Manchmal bin ja selbst ich noch überrascht. Da habe ich doch heute mal die FFT-Routine um den Faktor 2 beschleunigt. Bisher ergab ein Testprogramm für 1000 FFTs von 1024 Samples knapp 1,1 Sekunden. Saulangsam, aber plattformunabhängig, und ich habe mich nie drum gekümmert. Letzteres habe ich heute mal gemacht, und nun gehst also in knapp der Hälfte der Zeit von statten.

Der Geschwindigkeitsvorteil erhöht sich noch, wenn mehrere FFTs _auf_die_selben_Daten_ hintereinander angewandt werden. Das ist z. B. beim Wasserfall interessant, wo ziemlich viele FFTs auf die gleich Datenbasis angewandt werden. Bei der neuen Methode können das sehr viele (je nach Auflösung) mit ziemlich großen Längen (je nach unterer Grenzfrequenz) werden.

Bevor jetzt jemand denkt, ich habe mal wieder etwas Geniales geschaffen: die jetzt verwendete Methode (Vorrausberechnung der Koeffizienten und Speicherung derselben in einer lookup-table) ist ein sehr alter Hut, ich war bloß überrascht, dass die solche extremen Auswirkungen hat.

Eine merklich höhere Geschwindigkeit geht nach meinem Verständnis eigentlich nur noch durch Anpassung an eine spezielle Prozessorarchitektur, aber das will ich nicht (macht den Code komplizierter und damit fehleranfälliger)

Gruß
Cpt.

Sagt mal, bin ich eigentlich der Einzige der meine Webseite bzw. den Hoster nicht erreichen kann? Ich habe schon seit mehreren Tagen keinen Zugriff mehr, allerdings geht das CVS noch einwandfrei.

Edit:
Kaum geschrieben, schon geht das auch nicht mehr.

Gruß
Cpt.

Berlios hat immer wieder mit Ausfällen zu kämpfen. Irgendwann geht's dann wieder.

Aber so lange hat das noch nie gedauert.

Ich habs grad getestet, es geht wieder.

Gruß
Cpt.

Beta-Tester gebraucht

Moin,

die neueste Version ist so gut wie fertiggestellt, zumindest wird sich an der Funktionalität und den Kommandozeilenargument nichts mehr ändern.

Aber die Windows-Version macht mir Ärger. Deswegen brauche ich ein paar mutige Beta-Tester, um zu überprüfen, ob der Fehler an meiner Hardware oder am Programm liegt.

Zwei Probleme gibt es zu überprüfen:

1.) Unter Windows habe ich bei mir eine sehr hohe Latenz in der Audio-Ein-/Ausgabe festgestellt. 600ms sind ne ganze Menge Holz. Hier eine kurze Anleitung, was zu machen ist:

a) Testsignal erstellen, ein Sinuston von 100ms Dauer ist mehr als genug:

esweep generate sine -t 100 -o sinus.raw

An dieses Sinussignal muss unbedingt Stille angehängt werden. Dies ist in dieser Version neu hinzugekommen, dafür gibt es Gründe. Zuerst muss die Stille erzeugt werden, weil wir eine hohe Latenz erwarten nehmen wir 1 Sekunde:

esweep generate silence -t 1000 -o silence.raw

Und nun werden die beiden Signale aneinandergehängt:

esweep concat -o sinus.raw sinus.raw silence.raw

BTW, mit dem Parameter -r lässt sich bei der Generierung die Abtastrate verändern, Standard ist 44,1kHz. Der erste Befehl könnte dann also bei einer gewünschten Abtastrate von 48kHz lauten:

esweep generate sine -t 100 -r 48000 -o sinus.raw

Wichtig ist, dass beide Signal, Sinus und Stille, die gleiche Abtastrate haben, sonst lassen sie sich nicht zusammenfügen.

b) Mit diesem Signal eine Messung durchführen:

esweep measure -i sinus.raw -o resp.raw

Es muss keine akustische Messung sein, eine Direktverbindung zwischen Ein- und Ausgang der Soundkarte tut es auch.

c) Das aufgenommene Signal in Textform überführen und mit gnuplot darstellen:

esweep raw2ascii -i resp.raw -o resp.txt

Nun gnuplot aufrufen und mit

plot "resp.txt" w l

das Signal auf den Bildschirm bringen. Die Latenz ist die Zeit (x-Achse), die es bis zum Beginn des Sinus braucht.

Diese Zeit mir bitte, am besten auch mit Name der Soundkarte, mitteilen. Hier im Thread ist der geeignete Ort dafür.

---

2.) Unter Windows benimmt sich die FFT seltsam. Die Transformation eine Impulsantwort ergibt z. B. folgendes Bild:



Das geübte Auge wird natürlich sofort feststellen, dass es sich dabei um das Basis- und Spiegelspektrum handelt, wie es bei der diskreten Fouriertransformation auftritt.

Das eigenartige daran ist jedoch, dass es nur bei FFTs ab 4096 Samples Länge auftritt. Darunter (<=2048) ist alles in bester Ordnung. Und eben nur unter Windows, nicht unter OpenBSD.

Total bescheuert. Der Quellcode ist der gleiche, das ist reinstes ANSI-C, und ich habe nicht den blassesten Schimmer, woran es liegen könnte.

Das einzige, was mir da noch in den Sinn kommen könnte, sind Eigenheiten der eingesetzten Compiler (was letztendlich bedeuten würde, dass dort doch nicht alles ANSI-C ist, ich weiß aber nicht was), oder eben Windows-Schweinereien.

Was ich jetzt gerne wissen möchte ist, ob der Fehler unter Linux auch auftritt. Leider hat sich meine Linux-Installation selber vernichtet (wie eigentlich immer, was hab ich dem Betriebssystem eigentlich getan?), und ich bin zu faul, mir wieder die viele Arbeit zu machen.

Es muss sich also jemand finden, der esweep unter Linux kompilieren möchte. Dazu braucht man:

- eine Portaudio-Installation: ist äußerst einfach, Quellcode von http://www.portaudio.com herunterladen, entpacken, und dann im Verzeichnis von portaudio
./configure
make
make install (<- das letzte mit root-Rechten, also entweder mit su oder sudo)
Portaudio ist dann im Verzeichnis /usr/local/lib, das muss gegebenenfalls der Variablen LD_LIBRARY_PATH noch mitgeteilt werden. In der bash geht das folgendermaßen:
erst überprüfen: echo $LD_LIBRARY_PATH
Wenn da schon /usr/local/lib/ drinsteht, kann man sich die nächsten beiden Befehle sparen.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/
export $LD_LIBRARY_PATH

- den Quellcode von esweep, Link siehe unten

Die Kompilierung desselben ist dann äußerst einfach. Archiv entpacken, und im Verzeichnis esweep dann
make -f Makefile.Linux
make install (<- auch hier wieder root-Rechte)

Das Programm ist dann in /usr/local/bin, das Verzeichnis dann wenn nötig der Umgebungsvariablen $PATH hinzufügen (Vorgehensweise genau wie oben).

Nun kann getestet werden. Eine Impulsantwort ist ebenfalls unten in den Links zu finden, die ist 10ms lang (Abtastrate 44,1kHz).

Damit muss dann eine FFT durchgeführt werden:

esweep fft -i ir.raw -o fft.raw -l4096
esweep 2db -i fft.raw -o fft.raw

Der Parameter -l verlängert die FFT künstlich auf die angehängte Anzahl Samples. Dort können beliebige Werte stehen, das Programm rundet automatisch auf die nächstgrößere Potenz von 2 auf. Lässt man ihn weg, ermittelt das Programm die nötige Länge anhand der Samples im Input-File (hier: ir.raw).

Das Ergebnis muss dann in eine Textform überführt und mit Gnuplot dargestellt werden:

esweep raw2ascii -i fft.raw -o fft.txt

In gnuplot:

plot "fft.txt" w l

Das erscheinende Dia dann bitte mit dem oben gezeigten Vergleichen und das Ergebnis mir mitteilen.

Ich danke schonmal im Voraus für die Mitarbeit, wenn es Fragen gibt, dann ebenfalls bitte hier.

Die Links:

Windows-Binärversion: http://esweep.berlios.de/esweep-win-0.2.9.zip
Quellcode: http://esweep.berlios.de/esweep-src-0.2.9.tar.gz
Impulsantwort: http://esweep.berlios.de/ir.raw

Gruß
Cpt.

P.S.: wie es scheint, will mich Berlios verarschen. Ich bekomme selber wieder keinen Zugriff. Ich werde die Dateien gleich woanders bereitstellen.

P.P.S.: es geht ja gerade, also bleiben die Links erstmal so wie sie sind

Hallo,

da ich das tar-Archiv nicht runterladen konnte ( You don't have permission to access /esweep-src-0.2.9.tar.gz on this server.) habe ich mir die aktuelle Version aus dem cvs gehollt. Das Ergebnis sieht so

aus.

Um unter Linux zu übersetzen musste ich noch das Makefile.Linux und file.h anpassen.

Makefile: $(SRC)/sound_pa.c \ statt $(SRC)/sound_openbsd.c \

File.h:#undef __strsep einfügen
__strsep gibt es schon in der glibc (v2.5)

Gruß Thies

ths80 schrieb:

da ich das tar-Archiv nicht runterladen konnte ( You don't have permission to access /esweep-src-0.2.9.tar.gz on this server.)

Ich auch nicht, wie ich gerade feststelle. Die Zip-Datei und die Impulsantwort gehen aber, obwohl sie die gleichen Rechte haben. Ich sags ja: Berlios will mich verarschen.

Nun zu den wichtigen Sachen:

das Bildchen sieht natürlich genau so aus, wie es nicht sein sollte. Heißt: irgendwo ist da im Code etwas versteckt, dass der gcc unter Linux/Windows (MinGW) anders macht als der gcc unter OpenBSD. Oder es gibt noch irgendwelche klammheimliche Unterschiede in den Standardbibliotheken.

Denn so sollte es eigentlich aussehen:


Das habe ich unter OpenBSD gemacht, mit der gleichen FFT-Länge. Ich habe auch andere (größere) Längen probiert, kein Fehler.

Makefile: $(SRC)/sound_pa.c \ statt $(SRC)/sound_openbsd.c \

Der C&P-Teufel hat wieder zugeschlagen.

File.h:#undef __strsep einfügen __strsep gibt es schon in der glibc (v2.5)

Da schau her. Als ich letztens im Manual zur glibc nachgeschaut habe, war davon noch nichts zu sehen. Inzwischen ist da auch schon die Funktion strsep() selber enthalten. Scheint auch die gleiche Funktionalität wie das Original aus der BSD-Welt zu haben.

Dementsprechend habe ich das jetzt geändert, und meine strsep() (die auch nur ein direktes Kopieren aus dem OpenBSD-Quellcode ist, natürlich mit Copyright und allem) sollte jetzt nur noch gebaut werden, wenn noch keine vorhanden ist. Hoffe ich.

Danke für die Arbeit.

Gruß
Cpt.

Der zweite Fehler ist behoben (hoffe ich :D).

In der FFT berechne ich, die wievielte Potenz von 2 die FFT-Länge ist, das geht über den Zweier-Logarithmus (ld, logarithmus dualis) bzw. weil es den in der math.h (Standard-Mathe-Bibliothek) nicht gibt über die allgemein bekannte Umrechnungsformel ld=ln(Zahl)/ln(2).

Das ist natürlich eine Fließkommaberechnung, deswegen muss ich einen sogenannten Cast auf ganz Zahlen anwenden. Dabei werden die Zahlen hinter dem Komma abgeschnitten. Das ist natürlich dumm, wenn man eigentlich eine "3" erwartet, die Fließkommaberechnung aber wegen ihrer notorischen Ungenauigkeit "2,999..." errechnet - nach dem Cast wird daraus dann natürlich ne 2. In dem Fall der FFT bedeutet das nichts anderes, als dass dort plötzlich nur noch mit der Hälfte der Zahlen (sprich: Abtastwerte) gerechnet wird, was effektiv einer Halbierung der Abtastrate entspricht, und deswegen bekam ich das Spiegelspektrum mit rein. Die Lösung ist, diesen Wert zu auf die nächste ganze Zahl zu runden.

Scheinbar verhalten sich die Mathe-Bibliotheken von OpenBSD und Linux/Windows etwas verschieden - oder ich hab einfach immer Glück gehabt. Jedenfalls fallen mir noch etliche andere Stellen ein, wo der gleiche Fehler passieren könnte. Die werden jetzt ebenfalls überarbeitet.

Fehlt noch das erste Problem.

Gruß
Cpt.

Cpt._Baseballbatboy schrieb:

Das Bildchen mit K1 und K3 als CSD in einem Diagramm ist doch noch jedem in Erinnerung, ja? Nun, mit der neuen Methode schaut das so aus: ...

Genau zu diesem Bild hätte ich OT noch eine Anmerkung: Wie wäre es, wenn hier noch zusätzlich in ganz leichtem und transparentem Hellgrün bzw. Hellrot die komplette Fläche eingezeichnet wird und noch eine meinetwegen blaue oder schwarze Linie dort, wo sich beide Flächen schneiden. Ich denke, es könnte mitunter zu Verwirrungen kommen, welche Kurve wo genau verläuft bei entsprechende buckligen Graphen.

Die Saklierung ist hier für mich zumindest schwer zu erkennen. Auch denkbar wären doppelt so dicke Linien auf jedem fünften oder achten oder zehnten Skalierungsstrich (da müsste man halt probieren was besser kommt).

Gruß
Mohan123

Moin,

weil ich ja selber keine Grafikausgabe baue, sondern nur die Daten liefere, kommt es bei der Darstellung also auf das dafür verwendete Programm an. In dem Fall war es gnuplot. Das hat sicherlich etliche Möglichkeiten, aber die habe ich noch nicht alle raus. Möglicherweise lassen sich Deine Ideen da auch verwirklichen.

Ich hätte z. B. gerne wie bei MLSSA oder ARTA jedes Teilspektrum als Fläche, die die dahinter liegende verdeckt. In gnuplot scheint es sowas nicht zu geben, dafür aber eine Funktion names "hidden3d", die versucht, verdeckte Teil in so einem 3D-Diagramm auszublenden. So richtig doll ist das aber auch nicht.

Außerdem würde ich sagen, dass man sich die beiden CSDs normalerweise getrennt (bzw. nebeneinander) betrachtet.

Gruß
Cpt.

Ich habe gerad die Aktuelle cvs-version ausprobiert.

Ist da schon alles drin? Denn damit bekomme ich den gleichen fehler.

Ausserdem bekomme ich das Warning:
Warnung: Implizite Deklaration der Funktion »round«
Warnung: Unverträgliche implizite Deklaration der eingebauten Funktion »round«

bei jedem aufruf von round().

man round sagt dazu:
Compile with -std=c99; link with -lm.
bloß dan gibt es zig andere Fehler.
vielleicht solltest du einfach (int)(val+0.5) benutzen!

Gruß Thies

ths80 schrieb:

Ich habe gerad die Aktuelle cvs-version ausprobiert. Ist da schon alles drin?

Eigentlich schon.

Denn damit bekomme ich den gleichen fehler.

HASS!

Ausserdem bekomme ich das Warning: Warnung: Implizite Deklaration der Funktion »round« Warnung: Unverträgliche implizite Deklaration der eingebauten Funktion »round«

NOCH MEHR HASS!

vielleicht solltest du einfach (int)(val+0.5) benutzen!

Ist wohl auch die clevere Variante.

Ich probiers gleich nochmal unter Windows aus und meld mich dann.

Edit:
frag mich nicht, wie ich das geschafft habe. Aber ich habe dann (zurück im OpenBSD) in allen Dateien die Stellen mit den Casts geändert - nur nicht in der fft.c War zu faul, die zu kopieren.

Die Änderung muss in Zeile 27 von fft.c:

int runs=(int) (log10(input_size)/log10(2)+0.5);

Den Rest mach ich jetzt fertig und kommt dann nachher ins CVS.

Edit die 2.: ist jetzt im CVS.

Gruß
Cpt.

Moin,

jetzt funktioniert es so wie es soll.

Gruß Thies

Prima, nochmal danke für die Arbeit.

Das CVS ist jetzt auf dem Stand der kommenden Version 0.3, da wird also nichts mehr dran geändert, es sei denn, ich finde noch einen gravierenden Mangel. Das offizielle Release kommt, wenn ich die Anleitung fertig habe.

Gruß
Cpt.

[OT]
Es gibt hier doch bestimmt ein paar Nutzer der M-Audio Transit. Die soll ja auch ganz ordentlich sein.

Kann mir jemand sagen, welcher Chip in der Karte steckt? Eventuell ist das im Windows-Gerätemanager zu finden, oder im Handbuch. Auf der Webseite finde ich nichts dazu.

Ich spiele nämlich mit dem Gedanken, die zu erstehen, damit ich auch mit meinem Notebook messen kann (und die Hoffnung hege, dass die sich nicht ganz so biestig anstellt wie meine Terratec Six!Fire).
[/OT]

da wird also nichts mehr dran geändert, es sei denn, ich finde noch einen gravierenden Mangel.

Kennt Ihr Murphy?

Naja, eigentlich ist es kein wirklicher Mangel, sondern nur eine Unannehmlichkeit. Besser zwei Unannehmlichkeiten.

Die sind mir aufgefallen, als ich heute Abend meine Skripte auf Vordermann gebracht habe. Die eine Unannehmlichkeit - hat was mit der Umwandlung der Impulsantwort in eine Sprungantwort zu tun - ist behoben, die andere deucht mir noch etwas seltsam. Aber es ist nichts gravierendes.

Wo wir gerade bei Skripten sind:
meine eigene Skriptsammlung ist eigentlich nur Spielerei, aber ne schöne. Ich habe einfach mal versucht, die ganzen Messungen, die unsere bekannten Selbstbauzeitschriften in ihren Chassistests machen, nachzubilden. Nunja, Impedanzmessungen habe ich noch nicht drin (prinzipiell sind die aber schon seit esweep v0.2 ohne Einschränkungen möglich), dafür aber Intermodulationsverzerrungen mit Multiton. Inkl. Auswertung (Impulsantwort, Sprungantwort, Frequenzgang, Klirr, CSD (kennt Ihr eigentlich schon das hier: http://esweep.berlios.de/theorie/new_csd/new_csd_method.html ), IMD) braucht die ganze Prozedur ~10 Sekunden. Dabei legt das Skript (eigentlich sind es mehrere Skripte in einem zusammengefasst) die erforderlichen Verzeichnisse automatisch an. Und die Diagramme werden selbstverständlich von gnuplot als PNG gerendert. Wenn das kein Wort ist.

Vermutlich werde ich diese Skriptsammlung veröffentlichen, denn die ist wirklich gut geworden.

Gruß
Cpt.

Hallo Cpt.,

wenn mal Zeit ist. Was meinst Du zu dieser Problematik?

http://www.hifi-selbstbau.de/text.php?id=165&s=read

Gruß - Richard

Moin,

Version 0.3 ist jetzt draußen. Download am besten erreichbar über http://esweep.berlios.de

Was gibts neues:
- zahlreiche Verbesserungen, Fehlerbereinigungen, usw.
- ein paar neue Module, manche nützlich, manche nicht, manche zwingend notwendig
- die brandneue faltungsbasierte Methode des kumulativen Zerfalssspektrums (ja, ich bin ein kleines bisschen Stolz darauf)

@Richrosc: welche Problematik? Es ist ja nichts falsches, was die beiden erzählen. Auch die neue, von mir entwickelte, faltungsbasierte Methode ändert nicht daran: wenn Du einen Hochpass mit hoher Güte hast, dann schwingt das untenrum natürlich lange aus. Das geht gar nicht anders.

Gruß
Cpt.

'nabend Cpt.

Ein sehr schoenes Projekt. Die Theorie sieht interessant aus, und ich frage mich, ob z.B. aus dem Vergleich von Auf- und Absweeps ueber den gleichen Frequenzbereich eine noch bessere Trennung von Klirr- und Echoeffekten zu erreichen waere.

Deshalb ich habe gerade Version 0.3 'runtergeladen und versucht zu compilieren (Gentoo Linux), und das geht natuerlich nicht...

Das Problem liegt in der Version on Portaudio. Du hast offenbar version 1.1, ich habe 1.5. Die erste Funktion habe ich noch gerafft

(alt) Pa_IsStreamActive (neu) Pa_StreamActive

aber da bin ich dann auch haengengeblieben. Ich versuche es morgen noch mal.

Bis dann, gute Nacht.

cheers,
c2007

Hallo Cpt,

@Richrosc: welche Problematik? Es ist ja nichts falsches, was die beiden erzählen. Auch die neue, von mir entwickelte, faltungsbasierte Methode ändert nicht daran: wenn Du einen Hochpass mit hoher Güte hast, dann schwingt das untenrum natürlich lange aus. Das geht gar nicht anders.

Heißt das nicht, dass die Ergebnisdarstellung mittels Wasserfall, bei den tiefen FQ nicht genau sein kann.

Es werden also längere Nachhallzeiten im tiefen FQ-Bereich angezeigt also tatsächlich vorhanden?

Wahrscheinlich habe den verlinkten Text nicht ganz verstanden. Hatte ja mal berichtet, dass bei ARTA, Hobbybox und CARMA, selbst wenn ich nur die Soundkarte messe, im Tieftonbereich lange Nachhallzeiten angezeigt werden.

Dachte, dass könnte eine Erklärung sein.

Gruß - Richard

Moin,

c2007 schrieb:

Ein sehr schoenes Projekt. Die Theorie sieht interessant aus, und ich frage mich, ob z.B. aus dem Vergleich von Auf- und Absweeps ueber den gleichen Frequenzbereich eine noch bessere Trennung von Klirr- und Echoeffekten zu erreichen waere.

Es ist theoretisch durchaus möglich, statt eines aufwärts einen abwärts laufenden Sweep zu verwenden. Dann sind die Impulsantworten der harmonischen Verzerrungen nicht mehr vor, sondern hinter der der Grundwelle.

Ansonsten verstehe ich Deinen Post so, dass Du z. B. einen aufwärts laufenden Sweep abspielst und die Entfaltung dann mit einem abwärts laufenden Sweep machst. Das wird nicht funktionieren, da Du keine Impulsantwort erhälst.

Das Problem liegt in der Version on Portaudio. Du hast offenbar version 1.1, ich habe 1.5.

Eigenartige Versionsnummern. Ich habe mal gerade nach den ebuilds von gentoo geschaut, dort gibt es portaudio-19_pre061121.ebuild. Das ist eigentlich die aktuelle Version, leider als testing maskiert.

Alternativ kannst Du Dir auch die aktuelle Version von portaudio manuell herunterladen und installieren.

@Richrosc:
der Artikel berichtet nur darüber, dass ein Hochpass (wie er in einer Soundkarte drin ist) ein langes Ausschwingen auf seiner Resonanz (und ein gutes Stück darüber und darunter) hat. Das ist nun keine besonders neue Erkenntnis. Ist natürlich im klassischen Wasserfall ziemlich ärgerlich, weil es dadurch einige Verdeckungseffekte gibt. In auf Perioden normierter Darstellung würde das keinen so starken Effekt geben, weil dann die Zeitachse im Bass gestaucht ist (bzw. im Hochton gestreckt, wie mans nimmt). Aber bei sehr hohen Güten würde man solche Effekte auch bei periodisierter Darstellung erhalten.

Gruß
Cpt.

Moin moin,

Also noch mal in ausgeschlafenem Zustand:

Bei einem aufwaerts laufendem Sweep erscheinen die Harmonischen vor der Grundwelle. Bei einem abwaerts laufendem danach. Die Impulsantwort (Hall und Echo wenn ich richtig verstehe) aber immer danach.

Ich mache jetzt zwei Messungen: Eine aufwaerts und eine abwaerts. Jede entfalte ich mit der zugehoerigen Funktion. Dann bekomme ich zwei Spektren A(t) und B(t), die beide sowohl die Harmonischen als auch die Impulsantwort enthalten.

Ich nehme jetzt eines der (entfalteten) Spektren, sagen wir das abwaerts laufende, und drehe die Zeitachse um: Statt A(t) sehe ich mir A(-t) an, wobei t=0 die Grundwelle ist.

Wenn nur Harmonische dawaeren, dann wuerde es jetzt genauso aussehen wie das andere. Also enthaelt das Differenzspektrum A(-t)-B(t) nur die Impulsantwort, allerdings symmetrisiert: Die negative Impulsantwort vor dem Puls, und die "richtige" richtig danach.

Genauso muesste das auch fuer die Harmonischen moeglich sein, nur bin ich mir da nicht sicher ob es was bringt.

Bzgl. dem Versionswirrwarr um Portaudio sehe ich noch mal nach. Ich habe 1.5 installiert weil's die aktuellste stabile version fuer Gentoo ist. Ich versuch's mal mit 1.9. Die Versionsnummer 1.1 habe ich in dem Headerfile gefunden das im esweep 0.3 tar.gz distribution file ist.

Cheers und Danke fuer die schnelle Antwort.
c2007.

Moin,

c2007 schrieb:

Bei einem aufwaerts laufendem Sweep erscheinen die Harmonischen vor der Grundwelle. Bei einem abwaerts laufendem danach. Die Impulsantwort (Hall und Echo wenn ich richtig verstehe) aber immer danach.

Richtig.

Ich mache jetzt zwei Messungen: Eine aufwaerts und eine abwaerts. Jede entfalte ich mit der zugehoerigen Funktion. Dann bekomme ich zwei Spektren A(t) und B(t), die beide sowohl die Harmonischen als auch die Impulsantwort enthalten.

Nicht zwei Spektren, sondern zwei sehr lange Impulsantworten. Aus diesen sehr langen Impulsantworten lassen sich die Impulsantworten der Grundwelle und der harmonischen Oberwellen ausschneiden.

Ich nehme jetzt eines der (entfalteten) Spektren, sagen wir das abwaerts laufende, und drehe die Zeitachse um: Statt A(t) sehe ich mir A(-t) an, wobei t=0 die Grundwelle ist. Wenn nur Harmonische dawaeren, dann wuerde es jetzt genauso aussehen wie das andere.

Nein. Denn die einzelnen Impulsantworten haben, egal welchen Sweep Du wählst, die gleiche Form. Wenn Du die Zeitachse umdrehst, veränderst Du auch die Form (das "Ausschwingen" ist dann vorher). Im Frequenzbereich entspricht das im übrigen einer Vorzeichenumkehr des Arguments.

Vielleicht habe ich es auch noch nicht verstanden. Zumindest hast Du mich aber auf ein neues Modul gebracht: die Zeitumkehr (was haltet Ihr von dem Namen "flip"?). Kann sicher ganz nützlich sein.

Die Versionsnummer 1.1 habe ich in dem Headerfile gefunden das im esweep 0.3 tar.gz distribution file ist

Habe ich auch gerade gesehen, in der portaudio.h. Das ist eine interne CVS-Versionsnummer (meines CVS) und hat nichts mit der Versionsnummerierung von portaudio zu tun.

Gruß
Cpt.

1.) ich habe die neulich erwähnt Skriptsammlung online verfügbar gemacht: http://esweep.berlios.de/scripts.html
Bitte unbedingt die Anleitung dazu lesen.

2.) ich bin ungefähr zwei Jahre zu spät. Die Idee mit dem faltungsbasierten CSD hat schon ein gewisser John Kreskovsky (wer das wohl ist...) vor mir : http://www.pvconsultants.com/audio/stored/Stored-energy3a.htm

Shit. Na jedenfalls bin ich wohl immer noch der erste, der daraus einen Wasserfall gezaubert hat.

Gruß
Cpt.

Nochmals Shit! Den Wasserfall hat SoundEasy schon drin. Allerdings nur in zeitlinearer Darstellung.

Was anderes:

wenn jemand Fragen zum Programm hat, sei es Benutzung, Technik, oder irgendwelche Fehler findet: scheut Euch nicht, sie hier zu einzustellen.

Nur durch Feedback der Benutzer kann ein Programm besser werden.

Gruß
Cpt.

Hi,

ich werde dein Programmchen am WE mal testen. Es sieht einfach zu interessant aus...

Harry

Das ist doch mal ein Wort.

UNIX oder Windows?

Ich versuche gerade, die Skriptsammlung auf Windows zu portieren. Dazu benutze ich die Microsoft Services for Unix: http://www.microsoft...11778&DisplayLang=en

Sind >200MB, dafür hat man dann alle wichtigen UNIX-Tools (sed, awk, grep, ...) unter Windows zur Verfügung, mit einer UNIX-Shell (ksh und csh). Im Moment scheitere ich noch an der Umsetzung der Verzeichnis-Trennstriche (die Windows-Version von esweep möchte '\', die UNIX-Shell unter Windows hat aber '/' => Nervenzusammenbruch!)

Gruß
Cpt.

Die Skriptsammlung funktioniert jetzt auch unter Windows: http://esweep.berlios.de/scripts.html

Hoffe ich.

Gruß
Cpt.

Betriebsblindheit.

Seit den Anfängen dieses Projektes in grauer Vorzeit bin ich darauf aus, mit den logarithmischen Sweeps auch Klirrmessungen mit konstanter Lautstärke durchzuführen.

Mal kurz, was das heißt: bisher gehen nur Klirrmessungen mit konstanter Spannung, also z. B. 2.83V. Das gibt zwar nen netten Überblick, wo eventuelle Problemstellen sind, aber vergleichbare Aussagen zwischen zwei Chassis sind nicht drin, weil die eben unterschiedlich laut spielen, und vor allem keinen aalglatten Frequenzgang haben. Eine Messung ala "Klirr bei 90dB" und "Klirr bei 96dB" geht nicht so wirklich.

Das mit dem unterschiedlich laut spielen wird auch weiterhin nicht so einfach sein*, muss man per Hand ausgleichen. Aber den Frequenzgang künstlich glattbügeln, dass sollte doch wohl gehen (ist ja nichts anderes als ein Equalizer). Dazu wollte ich eine Funktion in den LogSweep-Generator einbauen, die anhand eines vorher ermittelten Spektrums den des Sweeps anpasst (so ganz ist die Idee auch noch nicht vom Tisch).

Und dabei habe ich genau diese Möglichkeit vor der Nase.

Die Theorie dazu: wenn ich ein beliebiges Signal mit der Impulsantwort eines Systems falte, erhalte ich die Antwort des Systems auf das Signal. Wenn ich stattdessen entfalte wird das System aus dem Signal herausgerechnet. Nichts anderes machen Entzerrer.

OK, und nun ein kleiner Monolog:

"Entfaltung!" Stille. "Deconvolution!". Stille, bis auf das leise Rattern von Relais und Zahnrädern. Irgendwo quietscht ne Tür. "de-con-volve!". AHA!

Ich habe doch das Module "deconvolve", mit dem man aus dem aufgenommenen Signal und dem Anregungssignal die Impulsantwort des gemessenen Systems errechnet. Und damit wären wir schon bei der Lösung des Problems: ich entfalte einfach den Standard-LogSweep mit der gemessenen (und gefensterten) Impulsantwort. Kinderleicht.

Und was soll ich sagen? Es funktioniert. Nachdem ich die Antwort des Lautsprechers auf den modifizierten LogSweep mit dem originalen entfaltet habe, erschien mir ein schnurgerader Frequenzgang (eigentlich ist die ganze Prozedur nur simple Bruchrechnung, und ja, ich weiß, das ich wegen dieser Aussage gefoltert werde ). Perfekt. Naja, nicht ganz, ein paar Welligkeiten waren noch drin, nachdem ich die Auflösung ein bisschen erhöht habe. Die waren aber weit unter 1dB, damit kann man leben.

Bilder zu der Sache gibt es demnächst, heute habe ich keine Lust mehr.

Oh, ganz nebenbei, 581 Hits auf die Webseite in der ersten Maiwoche, nicht schlecht, so langsam kommt die Sache ins Rollen. Zum Vergleich: gesamter März 1455, April 1686 Hits.

Gruß
Cpt.

*naja, was heißt nicht einfach: man reduziert den Ausgangspegel der Soundkarte, gleicht das durch ein wenig mehr Gain am Verstärker aus, so dass man bei der normalen Messung 2,83V hat, und dann wird per Skript die Lautstärke softwareseitig wieder angehoben, whatsthefuckin'problem?

Cpt._Baseballbatboy schrieb:

Kinderleicht...nur simple Bruchrechnung

Genau, geniale Lösungen sind immer einfach!

Sehr schön, ein weiteres Feature! Schmeiß aber bitte die andere Variante nicht raus.

Wollen wir nicht mal ernsthafter miteinander reden, "vielleicht" hat der Interessent für unsere Meßbox ja doch eine Verwendung für Dein geniales Progrämmchen, wenn, ja wenn es denn z.B. per Funktionstasten unter Windoof einfachst bedienbar wäre. Die Skripte oder Makros o.ä. sollten es doch irgendwie ermöglichen.
Arta kann zwar alles Mögliche, ist aber viel(!) zu umständlich.

Die Sache ist etwas komplizierter, aber hier nun die versprochenen Bildchen, garniert mit ein bisschen Anleitung zum Selbermachen.

Als erstes brauchen wir eine normale Frequenzgangmessung, den dazu nötigen Sweep haben wir schon vorbereitet. Das Ergebnis sieht dann so aus:



Ich habe die X-Achse absichtlich linear gelassen, damit der DC-Anteil noch enthalten ist.

Die transformierte Impulsantwort war 5ms lang, deswegen ist alles unterhalb 200Hz ungültig. Aber da beginnt das Problem: wenn man den Sweep mit dieser Impulsantwort entfaltet, dann bedeutet das eine Anhebung vom DC-Teil um >20dB, die Höhen werden sogar um >30dB angehoben. Oder andersrum gesprochen, die Mitten werden um 30dB abgesenkt, weil das Modul "measure" das Anregungssignal immer auf full scale normiert. Im Ergebnis würden wir dann keine Klirrmessung bei z. B. 90dB machen, sondern bei 60dB. Man müsste am Verstärker ein Gain von 30dB einstellen, das ist möglich, aber Unsinn.

Der Sweep nach Faltung mit dieser Impulsantwort würde so aussehen:


Ich habe mir natürlich ein wenig den Kopf zerbrochen, wie man das Problem lösen kann. Ich hatte schon Fensterfunktionen auf der Kappe, wollte mir den Sweep zurechtschneiden (das geht wunderbar mit dem Modul "ir"). Alles Blödsinn! Ich musste nur den Sweep richtig erzeugen. Dem Generator kann man nämlich mitteilen, in welchem Frequenzband der Sweep vollen Pegel haben soll (denn eigentlich läuft der immer von DC bis Nyquist). Weil die Probleme unterhalb von 200Hz beginnen, und oberhalb von 10kHz der Klirr sowieso von der Soundkarte rausgefiltert wird (Antialiasing-Tiefpass), erzeugte ich mir einfach mal einen Sweep in genau diesem Frequenzband:

esweep generate logsweep -o logsweep.raw -b 200 -e 10e3 -t 0.5

Neulich habe ich festgestellt, dass auch ein Sweep mit schlappen 500ms Dauer sehr gute Ergebnisse bringt. Der Default-Wert bei der Erzeugung ist 2 Sekunden, das ist ja viel zu lange.

Nun gut, dieser Sweep wieder mit der gemessenen Impulsantwort (ir.raw) entfaltet

esweep deconvolve -o logsweep_conv.raw logsweep.raw ir.raw

gibt dann dieses Bild:



Statt 30dB liegen nun zwischen dem Maximum um 200ms herum und dem lokalen Minimum bei 400ms nur noch 6dB. Das ist zu verkraften.

Also wird mit diesem Sweep gemessen (nicht vergessen, dass der Sweep vorher noch künstlich verlängert werden muss, siehe Anleitung):

esweep measure -i logsweep_conv.raw -o resp.raw -s -30

Die "-30" ist im übrigen recht interessant. Weil irgendwo in meiner Messkette ein (oder drei, oder fünf, oder...) Invertierer steckt, wäre der ermittelte Phasengang um 180° verschoben. Mit dem negativen Wert an dieser Stelle lässt sich das prima ausgleichen. Die 30 selber ist nur der Umrechnungsfaktor zwischen dem von der Soundkarte an das Programm gelieferten Wert und dem tatsächlichen Schalldruck (schon die AppNote zur Kalibrierung gelesen?).

Die Entfaltung muss nun im übrigen mit dem originalen - also nicht schon selber entfalteten - Sweep erfolgen:

esweep deconvolve -o ir.raw resp.raw logsweep.raw

Aus der gewonnenen Impulsantwort lassen sich nun nach dem (hoffentlich) bekannten Verfahren die Spektren der einzelnen Harmonischen berechnen. Für K1 und K3 sieht das dann z. B. so aus:



Wie man sieht, ist der Frequenzgang schnurgerade, das Verfahren funktioniert hervorragend.

Wie kann man das nun automatisieren?

Kein Problem: angenommen, man will Klirrmessungen bei 85dB und bei 95dB, wie es die K&T macht (gemacht hat? Ich krieg die hier nirgendswo zu kaufen). Dann benötigt man ein wenig Spielraum: "normale" Chassis erzeugen bei 2,83V mindestens 80dB Schalldruck, nur so komische Metallschalen, die unsereiner zum Kochen verwendet, sind manchmal leiser. Man muss also über wenigstens 15dB die Lautstärke automatisiert verändern können, wir nehmen hier mal 20dB.

Die Messungen werden dann mit einer um 20dB reduzierten Lautstärke durchgeführt, also so:

esweep measure -i logsweep.raw -o resp.raw -v -20 -s -30

Wer es noch nicht mitbekommen hat: die Lautstärke der Messungen wird ab der Version 0.3 in dBFS angegeben. Den Verstärker stellt man so ein, dass bei diesem Pegel am Lautsprecher die berühmten 2,83V anliegen. Damit führt man eine normale Messung des Frequenzgangs durch.

Dabei erhält man eine Impulsantwort, mit der man nach dem oben beschriebenen Verfahren einen vorverzerrten Sweep erzeugt. Alle dabei verwendeten Zahlenwerte (z. B. die Start- und Stopfrequenzen des Sweeps) lassen sich dabei ebenfalls automatisch errechnen.

Dann führt man die Messung erneut durch, ermittelt den Schalldruckpegel bei einer beliebigen Frequenz, berechnet die Differenz zum Sollwert (das Bild oben zeigt 80dB, 85dB und 95dB sind gewollt, Differenz ist somit 5dB bzw. 15dB), und führt dann die Messungen nochmal durch, mit angepasstem Ausgangspegel:

esweep measure -i logsweep.raw -o resp.raw -v -15 -s -30
esweep measure -i logsweep.raw -o resp.raw -v -5 -s -30

Fertig ist die Kiste. Wenn das nicht einfach ist.

@Timo:

meine Skriptsammlung habe ich inzwischen auf Windows portiert, leider ist da immer noch nichts mit Knöpfchen drücken. Für den Zweck habe ich gestern eine einfach Möglichkeit zur menübasierten Steuerung entdeckt, muss mich da aber noch einarbeiten und ich weiß nicht, ob es das auch für die Microsoftsche Unix-Umgebung gibt.

Ansonsten weiß ich ja, was ich machen muss, gell?

Gruß
Cpt.

Hi,

Fertig ist die Kiste. Wenn das nicht einfach ist.

Ich versuche noch zu verstehen!

Harry