| HIFI-FORUM » Do it yourself » Lautsprecher » Messtechnik / Grundlagen / FAQs » Entwicklung eines freien LS-Messprogramms | |
|
|
||||
Entwicklung eines freien LS-Messprogramms+A -A |
||||||||||||||
| Autor |
| |||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#1
erstellt: 06. Aug 2006, 20:33
|
|||||||||||||
|
Nabend zusammen, weil ich die Tücken und Lücken von Windows leid war, bin ich über Umwege bei den *BSD-Betriebssystemen angelangt - und glücklich. Auf meinem Hauptrechner läuft FreeBSD, auf meinem Notebook OpenBSD. Wie es der Zufall so will, gibt es für diese Betriebssysteme (und auch nicht für Linux, soweit mir bekannt) kein LS-Messsystem, alle nur für Windows. Das ist natürlich ein unhaltbarer Zustand, also habe ich mich daran gesetzt, eben diese Lücke zu schließen. Wie es ein weiterer Zufall so wollte, hatte ich im letzten halben Jahr eine Projektarbeit, wo es genau um so etwas ging: Entwicklung eines Messprogrammes, dass - schnell ist - Frequenzgang und Klirr misst Nach verschiedenen erfolglosen Versuchen mit Multisinusmessungen stieß ich auf die Theorie (und manch praktische Anwendung - natürlich nur für Windows) der logarithmischen Sweeps. Diese (kontinuierlichen) Sweeps haben in Kombination mit der richtigen Signalverarbeitung einige bemerkenswerte Eigenschaften: - beliebiges Betrags-Spektrum (der von mir aktuell eingesetzte hat ein rosa Spektrum) - logarithmische Gruppenlaufzeit - allgemein für Sweeps: hohe SNR Der zweite Punkt ist der entscheidende: durch ihn ist es möglich, indem man das empfangene Signal mit dem inversen Sweep faltet, sowohl den Frequenzgang als auch die Verzerrungen beliebiger (!) Ordnung in einem Durchgang zu messen. Diese "Entfaltung" erzeugt nämlich eine Funktion über der Zeit, in der in regelmäßigen Abständen die Impulsantworten der einzelnen Klirrkomponenten liegen. Tja, jeder der sich mit LS-Messtechnik beschäftigt hat ist sollte nun erstmal baff sein. Aber es funktioniert, wie meine Projektarbeit gezeigt hat. Dort war es auf K2 und K3 beschränkt, und das soll es bei diesem Programm vorerst auch, denn das reicht. Höhere Komponenten sind idR nur von akademischen Interesse. Zur Theorie ein bisschen Literatur: http://www.angelofarina.it/public/papers/134-AES00.PDFFür wen ist das Programm gedacht? Kurz: für jeden. Jeder darf es egal wofür, auch für kommerzielle Entwicklung, benutzen. Es ist mir egal, ich verfolge keinerlei kommerzielles Interesse mit diesem Programm. Einschränkungen des Programms Die Soundkarte. Zitat eines mir bekannten Entwicklers einer bekannten deutschen HiFi-Schmiede: "Soundkarten sind keine Messkarten." Das stimmt. Sie sind unzuverlässig, Rauschen, Klirren, Mixen ungefragt herum, sind schlicht und einfach limitiert und ein Ärgernis. Es gibt wenige gute - und die laufen dann natürlich nur unter Windows... Mit meinem Bolzen (Terratec Sixpack) hatte ich massig Probleme, bis da überhaupt mal was vernünftiges herauskam. Was kann das Programm bisher? Nun, genau das, was oben beschrieben ist: Frequenzgang und Klirr messen. Dabei ist es möglich, sowohl mit als auch ohne Raum zu messen, also durch Ausblenden der Reflektionen. Prinzipiell funktioniert es vollautomatisch: man startet es über die Kommandozeile, gibt ihm ein paar Parameter mit (wie Sweep-Dauer, Lautstärke, usw.) und dann dauert die Messung und Auswertung nur wenige Sekunden - auf einem modernen PC, meiner ist ein P4 mit 2,53GHz und 512MB RAM. Mehr Nutzereingaben sind nicht nötig und im Moment auch nicht vorgesehen. Womit wir schon dabei wären, was das Programm nicht kann: a) keine Kalibrierung b) keine grafische Darstellung Nun, Punkt a) steht bei mir ganz oben auf der Agenda, das sollte nicht allzu schwer werden. Punkt b) ist so eine Sache. Ich habe das Programm absichtlich als freie Software konzipiert, um anderen Programmieren die Möglichkeit zu eröffnen, es zu verbessern und eben auch eine grafische Ausgabe zu erzeugen. Denn ich habe, ehrlich gesagt, da nicht so viel Bock drauf, das verbraucht nämlich jede Menge Zeit. Ich hatte eher an Exportfilter gedacht, die die Daten in verschiedenen Dateiformaten ausgeben, die dann gängige Darstellungsprogramme (z. B. gnuplot) darstellen können. Noch ein Wort zu "freier Software": aktuell muss das Programm unter der GPL laufen, weil ich die FFT-Bibliothek fftw3 verwende, die ebenfalls unter der GPL veröffentlicht ist. Ist natürlich ein Unding, deswegen wird sobald wie möglich eine eigene performante FFT geschrieben und das Programm dann unter einer 2-Clause-BSD veröffentlicht. Auf welchen Betriebssystemen läuft es Tja, hier liegt einer der vielen Hunde begraben: bisher nur auf FreeBSD, weil ich es hier entwickelt habe. Die mathematischen Routinen sind alle in klarstem C geschrieben, die laufen überall, selbst auf nem Handy. Problematisch ist der Umgang mit der Soundkarte. Selbst OpenBSD (auf meinem Notebook) hat eine andere Schnittstelle zur Audioprogrammierung als FreeBSD (wobei es sich da nur um andere #define's handelt). Und dies ist wohl der richtige Moment, jeden Interessierten zu aktiver Teilnahme am Projekt einzuladen. Jede Erfahrung ist willkommen, am besten im Bereich Audioprogrammierung unter Windows, aber nicht nur. Ich bin kein Softwareentwickler, da kann ich noch eine Menge lernen. Den Quellcode verschicke ich gerne, wer ihn will kann mir seine Mail-Adresse mitteilen (am besten per PN). Ein paar Bildchen Zuerst ein paar allgemeine Kommentare: diese Grafiken wurden mit einem Programm erstellt, dass ich für meine Studienarbeit geschrieben habe. Es ist langsam, schwerfällig, und eigentlich nicht für so etwas gedacht, aber es verrichtet hier gute Dienste. Der aktuelle Datenexport ist auch auf dieses Programm zugeschnitten. Nochmal: dieses Grafikprogramm gehört nicht zum Projekt und wird auch nie dazugehören. In den Grafiken sind die schwarze Kurve die Grundwelle, blau K2 und rot K3. Die Messungen sind auf den Mittelwert der Grundwelle normiert, das wird sich ändern sobald die Kalibrierung funktioniert und dadurch auch Absolutpegelmessungen möglich sind. Das erste zeigt den Frequenzgang meiner Soundkarte, wenn per Softwaremixer der Ausgang auf den Eingang gelegt wurde (quasi intern verdrahtet). Man beachte die Klirrdämpfung von über 80dB, was einen Rückschluss auf die SNR zulässt (SNR muss größer sein; Messung ist reproduzierbar).  Das zweite ist wieder der Frequenzgang der Soundkarte, allerdings sind diesmal Eingang und Ausgang mit einem externen Kabel verbunden. Die Klirrwerte sind etwas schlechter, aber immer noch ordentlich.  Und zum Schluss eine Messung meiner kleinen popeligen ALR Jordan Entry2M. Dazu muss man sagen, dass hier die Raumeinflüsse nicht ausgeblendet wurden, der Lautsprecher auf dem Boden stand und das Mikrofon (Behringer ECM8000) auf einem Postpäckchen thronte. Hier herrschten also alles andere als gute Messbedingungen. Trotzdem ganz gut gelungen, nicht?  Und nun freue ich mich auf Feedback. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#2
erstellt: 07. Aug 2006, 22:33
|
|||||||||||||
|
Hallo Cpt.  Interessante Sache. Besonders die Entscheidung, mal eine Messsoftware für Unix auf die Beine zu stellen  Wie sieht's denn mit Linux aus? Ich hatte selber mal ein eigenes Meßprogramm für Windows programmiert. Die Entwicklung liegt aber seit ca. 2000 wegen Zeitmangels brach. Das Programm funktioniert aber für meine Bedürfnisse zufriedenstellend. Es kann Folgendes: - Messsignale: Sinus, rosa/weisses Rauschen, MLS - simples Oszilloskop-Fenster zur Pegeleinstellung - Setzen eines Gate-Fensters im Zeitbereich - Bei Rauschen/MLS: Kreuzkorrelation zur Errechnung der Impulsantwort - Aus der Impulsantwort: Frequenzgang, Wasserfall, Impedanz - Aus der Impedanz: TSP- und RCL-Messung - Klirrspektrum aus einem Sinussignal - Export der Frequenz-/Impdanzmessung - Speichern/Laden des aufgenommenen Zeitsignals - Drucken und Speichern (als *.EMF) des Analysefensters Hier mal ein paar Screenshots (je 100-170kB!) http://www.ggebler.de/lsm-w32/screenshot-lsm-2.jpghttp://www.ggebler.de/lsm-w32/screenshot-lsm-3.jpgMessobjekt ist der in die Box eingebaute Hochtöner Eton 25SD1 ohne Weiche. Gemessen mit einer unkalibrierten MCE-2000 Kapsel (deshalb der deftige Höhenanstieg). Die Möglichkeit des Einbindens einer Mikrofon-Kompensationsdatei fehlt leider noch im Programm  Das Ganze wollte ich dann auch mal auf Linux umsetzen. Ist aber dann auch eingeschlafen, da damals dauernd neue Versionen mit veränderten Programmierschnittstellen von GTK und ALSA herrauskamen. Außerdem hatte ich immer mit undefinierten Latenzzeiten zu kämpfen. Unter Windows ist's schon einfacher. Das Programm habe ich unter Win98 geschrieben und es läuft auch noch unter W2k (XP habe ich noch nicht probiert). Jedenfalls überlege ich, was ich mit dem Programm anfangen soll.  Ist ja eigentlich zu schade um es nur selbst zu nutzen.Zum Weiterentwickeln fehlt mir aber die Zeit (und ein wenig die Lust). Vielleicht sollte ich es unter der GPL-Lizenz veröffentlichen? Dann wird vielleicht mal was Vernünftiges draus  Richtig brauchbare Freeware ist mir immer noch nicht bekannt (außer evtl. Speaker-Workshop, ist mir persönlich aber zu umständlich). Gruß Guido PS: Das von dir gewählte Meßverfahren hört sich sehr interessant an. Mehrere Klirrverläufe in einem Rutsch messen zu können, hat schon was. Wie ist denn die Frequenzauflösung dabei? Jedenfalls fehlt eine solche Messung (Klirrfaktor als Funktion der Frequenz) in meinem Progrämmchen noch. Vielleicht könnte ich deine Routinen ja gebrauchen. Aber wie gesagt, ich habe selber wenig Zeit und Lust, daran weiter zu programmieren. Vielleicht findet sich ja jemand, der die beiden Programme zusammenwürfeln würde. Ich würde meine Sourcen (reines C, reine WinAPI ohne MFC o.ä.) durchaus dafür zur Verfügung stellen. [Beitrag von gundi am 07. Aug 2006, 23:18 bearbeitet] |
||||||||||||||
|
|
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#3
erstellt: 08. Aug 2006, 08:08
|
|||||||||||||
|
Moin,
Ist auch angedacht. FreeBSD nutzt OSS (Open Sound System) (bzw. was leicht abgewandeltes) als Audioschnittstelle, und das gibt es unter Linux auch, zur Not über den ALSA-Kompatibiliätsmodus.
Da rätsel ich auch noch daran herum. So eine Kompensationsdatei ist ja, soweit ich das weiß, auch nur ein abgespeicherter Frequenzgang mit einer festen Frequenzauflösung. Um das mit der veränderlichen Frequenzauflösung eines Messprogramms zu kombinieren (also durchführen der Kompensation) muss man da also, je nachdem welche Frequenzauflösung größer ist, interpolieren oder Stützstellen weglassen.
Ja, das ist eine der vielen kleinen Katastrophen an Linux, dass manch API nicht stabil ist.
Jepp. "Soundkarten sind keine Messkarten." Ich umgehe die Latenz, indem ich einfach einen genügend großen Block aufnehme, im Moment die 3fache Menge an Samples wie der Sweep selber hat. Das kommt aber bei längeren Sweeps schon nicht mehr hin.
Was für Win98 programmiert wurde läuft auch unter XP. Man sollte es nicht glauben: was eine stabile API angeht hat Windows Linux einiges voraus.
Beliebig. Oder besser: Samplingrate/2^N, ich verlängere die Impulsantworten immer auf Potenzen von 2 um die FFT-Geschwindigkeit auszunutzen. Die FFTW-Routinen sind zwar auch mit anderen Längen schnell, aber ich wollte die ersetzen und dann ist es mir zu viel Aufwand, die verschiedenen FFT-Ansätze alle zu implementieren. Dazu muss allerdings gesagt werden, dass die Frequenzgänge gestreckt sind, K2 um den Faktor 2, K3 um den Faktor 3 usw. Ein K2 bei z. B. 2kHz gehört eigentlich nach 1kHz. Das auszugleichen ist aber simpel und schon längst erledigt, wie die Grafiken zeigen.
Gerne. Gib mir Deine Mail-Adresse und ich schick die den Quellcode. Ist sogar kommentiert
Daran hätte ich natürlich Interesse, ich brauche aber nichts was mit Grafik zu tun hat. Wie schon geschrieben soll das erstmal außen vor bleiben, und wenn, dann natürlich idealerweise auch plattformunabhängig (also z. B. in GTK, Qt oder Tcl/Tk - kein Java, das die das plattformunabhängig nennen ist eine Frechheit). Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#4
erstellt: 08. Aug 2006, 12:30
|
|||||||||||||
Mahlzeit,
OSS hat einen ALSA-Kompatibilitätsmodus? Ich meine, es ist umgekehrt, jedenfalls unter Linux. Ich hatte damals mit ALSA größere Schwierigkeiten als mit OSS, eine Soundblaster-Karte (SB16 oder SB-Live) mit FullDuplex an's Laufen zu bekommen.
Hihi, das ist genau das Problem, vor dem ich auch stand  . Es müssten nach jeder FFT passende Kompensationswerte z.B. durch Spline-Interpolation generiert werden (so macht's wohl ARTA). Das habe ich immer vor mir her geschoben, obwohl es vielleicht gar nicht so aufwendig wäre
Naja, vielleicht sieht die Sache ja mittlerweile besser aus. Ist ja immerhin ca. 6-7 Jahre her, als ich es versuchte.
Ich denke, es liegt nicht unbedingt an den Soundkarten. Unter Windoof funktioniert's ja. Unter Linux startete die Messung aber immer zu leicht unterschiedlichen Zeitpunkten. Das ist blöde, wenn man periodische Signale, also auch MLS und die von mir verwendeten Rauschsignale, über mehrere Messungen mitteln möchte.
Nicht ganz. Neuere Treiber (z.B. für meine Terratec XFire 1024) unterstützen die MMS-Api (Microsoft-Media-System WIMRE) nicht mehr, sondern nur noch DirectSound. Also, auch unter Windows werden mitunter die APIs gewechselt 
Ich mache es mir noch einfacher. Ich rechne intern immer mit einer festen FFT-Länge (4096 WIMRE). Das ließe sich zwar einfach durch ein #define im Sourcecode ändern, ist aber nicht durch den Benutzer einstellbar
Supi, schick ich dir in Kürze. Mal sehen, ob ich da schlau draus werde, ich habe schließlich ein paar Jährchen nicht mehr programmiert. Wer weiß, ob ich überhaupt noch durch meinen eigenen Sourcecode durchblicke (der ist fast null kommentiert, aber recht ordentlich gegliedert) .
Na was denn nun, Interesse oder nicht? Ist halt nicht plattformunabhängig. Aber vielleicht kannst du die Sound-I/O Routinen brauchen? Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#5
erstellt: 08. Aug 2006, 13:08
|
|||||||||||||
|
Moin,
Genau so rum meinte ich es. Aber stimmt, meine Formulierung war grad diametral entgegengesetzt
Ja, aber es ist erstmal Arbeit. Wahrscheinlich würde sogar erstmal eine lineare Interpolation zwischen den Stützstellen vollkommen ausreichen, man muss ja nicht gleich die Artillerie auffahren. Wäre wohl der Zeitpunkt, jemanden um so eine Datei zu bitten. Kann mir jemand eine zusenden? Oder nen Downloadlink bereitstellen?
War auch eher allgemein gedacht. ALSA dürfte inzwischen wohl stabil sein. Aber vor ein paar Monate gabs doch Ärger mit AVM wegen einer urplötzlich geänderten API.
Hmm. OSS soll ja eine relativ hohe Latenz haben, kann ich hier nicht ganz nachvollziehen, müsste aber nochmal genauer nachmessen. Zumindest ist sie aber ziemlich stabil.
Heute kann man sich auch auf gar nichts mehr verlassen 
Klar, geht auch. Dabei verschwendest Du aber SNR. Wenn Du z. B. eine 10ms lange IR hast (macht bei 44,1kHz 441 Samples) und die dann auf 4096 Samples verlängerst (vermutlich mit vielen 0, so wie ich), dann geht einiges an SNR bei drauf. Bei mir wären es lediglich 512 Samples, also weitaus besseres Verhältnis. Was für eine FFT benutzt Du denn? Selbst geschrieben?
Genau, die wären Klasse. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#6
erstellt: 08. Aug 2006, 14:50
|
|||||||||||||
Ist nix Besonderes, einfach eine Textdatei mit Frequenz und Pegelwerten. Pro Zeile: Frequenz <TAB> relativer Pegel
Naja, vielleicht war ich zu blöd, um ALSA richtig zu programmieren. Oder ALSA war damals noch zu wackelig (war noch Version 0.9x oder so)
Ja, schön mit Nullen aufgefüllt. Könnte sein, daß ich da SNR verschenke. So genau kenne ich mich mit der FFT auch nicht aus. Die erzeugten Kurven wirken aber etwas "smoother"
Ich glaube, die FFT war in den 80er Jahren mal in einer c't abgedruckt. Da gab's früher so schöne Bastelprojekte (vor allem für den Atari ST). Für irgendeine A/D-D/A-Wandler Karte für den ST wurde da mal eine FFT-Routine abgedruckt. Mann, das waren noch Zeiten. Mit dem Atari hatte es damals bei mir angefangen. Zuerst mit einer 8-bit DA/AD-Karte für den ROM-Port. Die 8 MHz reichten dann aber schnell nicht mehr und die 8-Bit Auflösung war auch etwas dürftig für vernünftige Messungen Dann hatte ich es mal mit einer externen DSP56k-Karte mit integriertem 16-Bit Codec (alles am seligen Atari) versucht. Die FFT (in DSP56k-Assembler) ging dann zwar sehr fix, die Daten Hin- und Herschaufelei über den ROM-Port war aber dann der Flaschenhals. Schließlich bin ich dann schweren Herzens zum PC gewechselt.
OK, ich schau' heute Abend mal, daß ich dir was rübermaile. Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#7
erstellt: 08. Aug 2006, 15:42
|
|||||||||||||
Nichts davor? Irgendein Header? Ansonsten ist das ja einfach, meine Kalibrierungsdatei sieht nicht anders aus.
Ja, das waren noch Zeiten. Ich lernte gerade schreiben...
Hast PN wegen Mail-Adresse. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#8
erstellt: 09. Aug 2006, 09:53
|
|||||||||||||
Nun, bei ARTA ist es so, daß es alle Zeilen einliest, die als erstes Zeichen eine Zahl enthalten. Alle anderen Zeilen werden als Kommentar behandelt. Also ziehmlich simpel.
Du hast auch Post |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#9
erstellt: 09. Aug 2006, 10:45
|
|||||||||||||
Ein bisschen sehr simpel. Eines habe ich schon mit meiner noch recht jungen Programmiererfahrung gelernt: User sind Arschlöcher die sich prinzipiell immer Neues einfallen lassen, um das Programm in die Irre zu führen.
Habs schon geladen. Will mal sehen, wie ich die Audiosachen gebrauchen kann. Hab da was nettes entdeckt: http://www.portaudio.com Eine plattformübergreifende Audio-I/O-API. Das scheint für meine Zwecke das richtige zu sein. Leider nicht für OpenBSD, aber das bekomm ich auch noch hin. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 09. Aug 2006, 20:24 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#10
erstellt: 11. Aug 2006, 07:12
|
|||||||||||||
|
Moin Cpt., interessanter Link (Portaudio). Damit und mit QT/GTK für die Grafik müsste doch etwas plattformübergreifendes machbar sein. Mal 'ne andere Frage, da du dich ja recht gut mit diversen Messverfahren auszukennen scheinst: Ich hatte bei meinem Programm immer ein Problem bei der Messung mittels MLS. Selbst wenn ich die Soundkarte im Loopbackmodus (Ausgang und Eingang direkt miteinander verbunden) betreibe, kommt da (nach der Kreuzkorrelation von linkem und rechten Kanal und anschließender FFT) immer ein bei hohen Frequenzen ziehmlich zappeliger Frequenzgang raus. Messungen mit rosa/weißem Rauschen funktionieren einwandfrei. Nur ist da der Rauschabstand etwas geringer. Bei Mikrofon-Messungen sind die Ergebnisse per MLS besser (wegen Bandbegrenzung der Lautsprecher, des Mic-VV ?) 1) Ist das normal bei einer MLS? 2) Benötigt man einen ordentlichen Hochpass vor dem Eingang? 3) Oder ist die MLS-Erzeugung nicht korrekt? Zu 3) Wenn ich einen Aufnahmebuffer/FFT-Länge von 8192 Punkten verwende, wie lang muß dann die MLS sein (8191, 8192, doppelt so lang, ...)? Hast du vielleicht eine gute Routine zur Erzeugung der MLS? Gruß Guido [Beitrag von gundi am 11. Aug 2006, 07:14 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#11
erstellt: 11. Aug 2006, 08:26
|
|||||||||||||
Was ich an MLS probiert habe hat auch nie richtig geklappt. Ich hatte immer eine grausige Impulsantwort, mit vielen hohen Peaks die da nicht hingehörten. An das Spektrum kann ich mich nicht mehr erinnern. Jedenfalls war es nicht ganz so schlimm, wenn ich statt der FHT eine sintknormale Kreuzkorrelation durchgeführt habe. Wobei die FHT nicht falsch war, simuliert hat sie einwandfrei geklappt (und auch das notwendige Permutieren). Den Grund dafür konnte ich mir aber nicht erklären.
Sollte sich eigentlich in der Soundkarte befinden, von wegen Shannon/Nyquist.
Die Länge der MLS ist für die FFT egal, da kommt es nur auf die SNR an, je länger umso höher (und umso geringer der DC-Anteil). Nur sollte die MLS oft genug abgespielt werden (ohne Pause), bis Du aus der Aufnahme ein vernünftiges Stück herausschneiden kannst. Das kreuzkorrelierst Du dann mit der erzeugten (bei Einkanalmessung) oder mit der über den anderen Kanal (bei Zweikanal) aufgenommenen. Ich hatte festgestellt, dass man die MLS mindestens 3mal abspielen muss um vernünftige Ergebnisse zu erhalten. ---- Zu Portaudio: gestern habe ich nach Anleitung mal versucht, mein Programm mal unter Windows zu bauen. Ging natürlich schief, weil die Doku von Portaudio in der Beziehung Müll ist. Unter FreeBSD war es in den Ports (dem Quellcode-/Paketsystem von FreeBSD) und schon installiert. Schön ist aber, dass Portaudio eine BSD-artige (2-clause) Lizenz hat, das passt mir sehr gut. Qt oder GTK sind ganz nett, aber besonders Qt ist leider nur unter der GPL zu haben, das heißt auch die damit erstellte Software muss unter die GPL. GTK steht unter der LGPL, da müsste ich mich mal genauer informieren wie das aussieht. Tcl/Tk wiederum hat eine BSD-artige Lizenz, liegt also ganz auf meiner Linie. Und da ich noch nie was mit Tcl/Tk gemacht habe, wäre es somit - sollte ich wirklich noch was grafisches drumherum machen - das Werkzeug der Wahl. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#12
erstellt: 12. Aug 2006, 21:27
|
|||||||||||||
|
Heute - nach langem Ringen, das wesentlich kürzer ausgefallen wäre, wenn ich nur halb so doof wär - habe ich meine eigene FFT/IFFT-Implementation fertiggestellt. Sie funktioniert, auch hinreichend schnell. Für praktisch relevante Sweep-Längen genauso wie die angeblich schnellste FFT im Westen (FFTW). Bei einem 6 Sekunden langen Sweep (bei 44,1kHZ Abtastrate sind das 264600 Samples, die durch die "Entfaltung" nochmal auf das knapp 4fache erhöht werden) knapp 10 Sekunden. Das sollte reichen. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#13
erstellt: 15. Aug 2006, 19:42
|
|||||||||||||
|
Nun wirds offiziell :ich habe das Projekt bei Berlios gehostet, die URL ist http://esweep.berlios.de (da ist noch keine Homepage, Ihr werdet auf die Berlios-interne Projektseite weitergeleitet). esweep wegen exponentieller Sweep, das war der erste Begriff unter dem ich die Technik kennengelernt habe, und unter dem Namen habe ich das Projekt privat schon einige Zeit auf dem Rechner. Ich werde weiterhin Neuigkeiten hier posten, detaillierte Informationen gibt es aber auf der Projektseite. Achja, wer mitentwickeln will darf sich dort gerne anmelden. Nur keine falsche Scheu, ich nehme auch blutige Anfänger. Da kann man ja schließlich was lernen, ich programmiere auch erst seit knapp einem Jahr sinnvolle Sachen. Ich denke, dass ich in ein paar Tagen den Quellcode hochgeladen habe. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#14
erstellt: 16. Aug 2006, 09:34
|
|||||||||||||
|
Ging schneller (weil einfacher) als gedacht: der Source-Code ist online. Man kann ihn online ansehen oder herunterladen, zum selber bearbeiten würde ich aber einen CVS-Checkout empfehlen. Wie das geht, steht in der Doku zu Berlios. Gruß Cpt. |
||||||||||||||
|
Röhrender_Hirsch
Inventar |
#15
erstellt: 16. Aug 2006, 09:53
|
|||||||||||||
Hallo, es freut mich immer, wenn auch mal was unter "alternativen Betriebssystemen" entwickelt wird. Unter "Linux" bzw. KDE läuft KDSP, wobei ich mich nicht genügend mit der Materie beschäftigt habe um es mit deinem Projekt vergleichen zu können. Es liess sich jedenfalls problemlos auf meinem Debian übersetzen. KDSP Thread: http://www.nubert-forum.de/nuforum/ftopic11264.htmlHomepage: http://www.thilomaurer.de/kdsp.htmlGrüße [Beitrag von Röhrender_Hirsch am 16. Aug 2006, 11:36 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#16
erstellt: 16. Aug 2006, 11:29
|
|||||||||||||
|
Das kannte ich noch nicht, optisch ist es aber sehr ansprechend. Scheint mir aber eine andere Zielrichtung zu haben, das Messen von Lautsprechern ist nur eine Dreingabe. Außerdem verwendet er MLS zur Frequenzgangmessung (wie rückständig ), und, soweit ich den völlig undokumentierten Quellcode verstanden habe, zur Klirrmessung einen Einzelsinus. Das wäre aber z. B. so ein Projekt wo ich überhaupt kein Problem damit hätte, wenn er meine Algorithmen benutzt. Dafür ist das gedacht. Vielleicht kann ihn ja mal jemand darauf hinweisen. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 16. Aug 2006, 11:30 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#17
erstellt: 22. Aug 2006, 15:33
|
|||||||||||||
|
Achtung, Theorie: ein umfassender, zu verstehender Überblick auf bekannte Messverfahren und besonders auf Sweeps: http://www.anselmgoe.../aes-swp-english.pdfBesonders beruhigt mich, dass die Beschreibung der Erzeugung des Sweeps im Frequenzbereich (und dann per IFFT in den Zeitbereich tranformiert) sich mit meinen eigenen Berechnungen deckt. Ich bin also doch nicht völlig verblödet. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#18
erstellt: 24. Aug 2006, 10:18
|
|||||||||||||
|
Gestern habe ich loagrithmische Sweeps mit weißem Rauschen getestet. Das Ergebnis ist ernüchternd: man hat eine dermaßen geringe SNR dass es einem die ganze Messung versaut. Also bleibt es bei einem rosa Spektrum, damit sind Konstantpegelmessungen nicht möglich. Finde ich aber nicht ganz so schlimm, immerhin entspricht das der Realität. Und besser als mit logarithmischen Sweeps kann man in der Heimwerkstatt Klirr eh nicht vernünftig messen. Oder hat jeder von Euch einen RAR zuhause? Und MLS-Messungen kommen sowieso nicht mit. Ich werde noch die Sweeperzeugung ein wenig verbessern, mit sanftem Ein- und Ausblenden, das reduziert einige Artefakte am oberen und unteren Ende der Messung. Gruß Cpt. |
||||||||||||||
|
Röhrender_Hirsch
Inventar |
#19
erstellt: 24. Aug 2006, 13:27
|
|||||||||||||
|
Ich lese den Thread auf jeden Fall interessiert mit, kann aber kein Wissen beitragen. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#20
erstellt: 24. Aug 2006, 15:37
|
|||||||||||||
Tja, das mit dem Ein- und Ausblenden ("Fenstern") ist so eine Sache, wie ich feststelle. Zwar wird die Welligkeit des Spektrums vom Sweep verringert, dafür handelt man sich aber zu beiden Enden hin sehr niedrige Werte ein (im Bereich von 0.5m, absolut). Wieso das ein Problem ist? Nun, wer die Theorie gelesen hat weiß, dass bei dieser Technik die Faltung zum Einsatz kommt. Und zwar wird das empfangene Signal mit dem inversen Sweep gefaltet, so erhält man dann die Folge von Impulsantworten. Die Faltung ist aber eine sehr aufwändige Operation, sie hat einen Aufwand von N² Multiplikationen, eine doppelte Anzahl an Samples erfordert die vierfache Menge Zeit. Nun kann man aber die Faltung, indem man die zu faltenden Signale (hier: das empfangen Signal und der inverse Sweep) fouriertransformiert, als einfach Multiplikation ausführen, und dann zurücktransformieren. Aus Faltung(a(t), b(t)) wird A(w)*B(w) (A(w) und B(w) sind die Fouriertransformierten von a(t) und b(t)). Man benötigt folglich 3 Fouriertranformationen und N komplexe Multiplikationen, mit einer FFT ergibt das einen Aufwand von 2*N+3*N*ld(N). Man mag es nicht glauben, aber schon bei einer Sweep-Länge von lediglich zwei Sekunden und einer Abtastrate von 44,1 kHZ ergibt das eine Zeitersparnis um den Faktor ~500 (wenn ich mich jetzt nicht gründlichst verrechnet habe). Das sollte man ausnutzen. Nur hat die Sache einen Haken. Den inversen Sweep erhält man am einfachsten, indem man den Sweep fouriertransformiert, invertiert und wieder zurücktransformiert. Oder, um sich das zu sparen, passt man die Faltung etwas an, man macht aus A*B einfach A/B. Diese Multiplikation (Division) erfolgt diskret, das heißt jede Stützstelle (also z. B. bei 1Hz, 2Hz usw.) wird einzeln berechnet (daher die zusätzlichen 2*N Multiplikation, zweimal weil komplex). Der geschulte Mathematiker wird natürlich sofort ein Problem erkennen: was, wenn B an einigen Stützstellen gegen 0 geht oder sogar 0 selber erreicht, dort also eine Nullstelle ist? Das Ergebnis sieht man auf diesem Bild:  Großer Bullshit. Dieses Spektrum entstand mit einem Cosinus-Halbfenster über eine Terz, jeweils am Anfang und am Ende des Sweeps. Am Anfang (also bei tiefen Frequenzen) scheint es seine Wirkung sowieso zu verfehlen, aber am oberen Ende, oberhalb von 20kHz (der Sweep ging von 20-20.000Hz), wurde der Betrag des Spektrums sehr klein, und dann ergibt sich eben so ein Ausreißer. Also muss ich ein Fenster finden, dass nicht ganz so stark unterdrückt, ein Hamming-Fenster scheint mir da sehr vielversprechend (das Spektrum dieses Fensters hat eine ziemlich schmale Nebenkeule, dafür noch recht kräftige Nebenkeulen, hier in meinen Unterlagen gerade mal eine Dämpfung von 50dB, das sollte genügen - und ich hab das Fenster immer für untauglich gehalten ). Ich werd das mal testen. Edit: Das war ja einfacher als Kirschenessen (nämlich nen Klacks, ich mag keine Kirschen):  Das Fenster ist nahezu perfekt, ich werde noch ein paar Bilder vom Spektrum eines Sweeps posten, darauf sieht man das dann genauer. Jedenfalls habe ich mit diesem Fenster als Minimum irgendwas um 0,2, also ein Wert, der klein genug und dennoch keine eklatanten Fehler mehr verursacht. So, da sind sie schon:  Hier ist das Spektrum eines 2 Sekunden langen Sweeps von 20Hz bis 20kHz bei einer Abtastrate von 44,1kHz zu sehen. Rot war gar nicht gefenstert, schwarz mit einem terzbreiten Hamming-Halbfenster und blau mit einem Oktavbreiten. Man erkennt deutlich die Einflüsse auf den Ripple (der sich aus der Bandbegrenzung des Sweeps ergibt und irgendwas sinc-artiges ist). Mich selber wundert nur, dass das terzbreite Fenster im Tieftonbereich schlechter abschneidet als die völlig ungefensterte Variante (schwarz hat mehr Ripple als rot). Sollte mir da ein Fehler unterlaufen sein? Wie dem auch sei, hier ein detaillierter Ausschnitt aus dem oberen Ende:  Hier ist ganz klar die gefensterte Variante in Front, Farben sind wie oben. Das oktavbreite Fenster dämpft schon zu sehr, das terzbreite ist hier optimal, das bisschen Ripple kann man verschmerzen, wenn man bedenkt, dass der gewaltige Ripple des ungefensterten Sweeps trotzdem schon ordentliche Messungen zugelassen hat. Vielleicht ist die Lösung, am Anfang und am Ende des Sweeps unterschiedliche Fenster einzusetzen. Ich werde das mal bei nächstbester Gelegenheit testen. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 24. Aug 2006, 16:05 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#21
erstellt: 25. Aug 2006, 10:02
|
|||||||||||||
|
Hab mal ein paar Fensterarten verglichen, mit einem Sweep von 2 Sekunden Länge, 20-2000Hz und 8kHz Abtastrate. Am oberen Ende bleibt es beim Hamming-Fenster, untenrum habe ich heute experimentiert.  Das Bild zeigt den interessantesten Ausschnitt, da wo am meisten Ripple vorhanden ist. Blau: Hanning Grün: Hamming Rot: Rechteck Schwarz: Blackman Das Rechteckfenster ist als Kandidat eindeutig disqualifiziert, nicht nur wegen dem exzessiven Ripple, auch wegen dem (hier nicht sichtbaren) hohen Anteil an tiefen Frequenzen (und hohem DC-Anteil). Hamming und Hanning (eigentlich heißt es Hann, weil Julius von Hann der Entwickler war, ich bleib aber bei Hanning) tun sich nicht viel, weder beim Ripple noch beim DC-Anteil, beides sehr gering. Das Blackman-Fenster zeigt dagegen wieder erhöhten Ripple und auch der DC-Anteil ist größer als bei den beiden H.-Fenster, aber immerhin deutlich kleiner als beim Rechteck. Hamming und Hanning sind somit die klaren Gewinner, vorerst, denn ich werde noch andere Fensterarten testen, wie z. B. verschiedene Kaiser-, oder ein Blackman-Nuttall-Fenster, welches mir für diesen Zweck sehr interessant erscheint. Wer sich mehr für die Fensterfunktionen interessiert sollte sich mal den englischen Wikipedia-Artikel dazu antun, der deutsche taugt nichts: http://en.wikipedia.org/wiki/Window_functionEdit natürlich ist auch interessant, wie sich die verschiedenen Fenster denn nun auf eine Messung auswirken. Dazu habe ich meine Soundkarte mit den 4 verschiedenen Fenstertypen von oben gemessen, heraus kam dieses (Farben wie oben):  Die obere Kurve zeigt die Grundwelle, dort ist nichts nennenswertes zu erkennen, die 4 Messungen sind quasi deckungsgleich. Die 4 unteren Kurven zeigen die erste Harmonische, also K2. Die Unterschiede sind gering, aber doch deutlich. Das Hanning-Fenster (blau) schneidet am schlechtesten ab, knapp durch Blackman (schwarz) geschlagen. Rechteck und Hamming tun sich nichts. Damit steht das Hamming-Fenster vorerst als Sieger des Ausscheidungswettbewerbs fest, mal sehen, wie es sich gegen die schon erwähnte Kaiser- und Blackman-Nuttall-Fenster schlägt (wenn ich die fehlerfrei implementiert habe). Ich vergaß zu erwähnen, dass die Fensterbreite je eine Oktave war. 2. Edit Ich möchte darum bitten, die letzten Messungen nicht überzubewerten. Der K2 rangiert an der Grenze der Messgenauigkeit, die Unterschiede zwischen den Kurven sind also mit Vorsicht zu genießen. Außerdem habe ich ein Fenster unterschlagen: Bartlett. Was soll man sagen: es rippelt weniger als Hamming, ist also noch ein Stück besser. 3. Edit Scheiß aufs Kaiser-Fenster! Ich hab nämlich keinen Bock, mir hier erst noch ne modifizierte Besselfunktion hinzuhacken. Bartlett und Hamming funktionieren ausreichend gut, man muss es ja nicht übertreiben. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 25. Aug 2006, 13:53 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#22
erstellt: 25. Aug 2006, 22:00
|
|||||||||||||
|
Hallo Jochen, damit du hier nicht den Alleinunterhalter spielen musst ;), habe ich jetzt auch wieder das Programmieren angefangen. Zunächst habe ich mal deine gen_sweep() Funktion in mein Programm eingebaut. Allerdings erstmal ohne die Fensterfunktionen. Da mein Programm mit fixen 4096 Samples arbeitet, erzeuge ich einen Sweep von Fu=Fs/800 bis Fo=Fs/2.2, also 5-1818 Hz bei 4 kHz Samplingrate und 60-21818 Hz bei 48 kHz. Der Sweep wird dann 2 mal hintereinander (aus einem 8192 Punkte Buffer) abgespielt, damit auf jeden Fall ein kompletter Sweep aufgenommen wird. Das Ergebnis sieht dann so aus: http://ggebler.onlinehome.de/lsm-w32/Sweep3.jpg Die Welligkeit im Spektrum wird ja von dir derzeit genauer untersucht , läßt sich aber mit ein wenig Smoothing sehr gut eliminieren.Hier eine Impedanzmessung (oben Phase, unten Impedanz) mittels Sweep an einem 17er TMT mit 4 kHz Abtastrate:  Ist leider etwas welliger als mit rosa oder weißem Rauschen. Hier der gleiche TT mit 48 kHz Abtastrate:  Das sieht doch schon ganz gut aus! Ich habe mit schlechteren Ergebnissen gerechnet, wenn man bedenkt, daß mein Sweep bei 48 kHz gerade mal 85 ms dauert Ich muß noch meinen Mic-VV flicken, dann mache ich mal eine akustische Messung. Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#23
erstellt: 26. Aug 2006, 08:02
|
|||||||||||||
Schön. Dafür wars gedacht.
Das solltest Du ändern. Wirklich. Zumindest für die Bearbeitung des Sweeps.
Da bin ich mir nicht sicher, ob das funktioniert. Scheinbar ja, die Ergebnisse sind ja ganz ordentlich.
Die Welligkeit der Impedanzkurve hat nichts mit der Welligkeit des Sweep-Spektrums zu tun, die wird durch die Entfaltung eliminiert. Das muss woanders herrühren. Meine Versuche, die Welligkeit im Sweep-Spektrum zu eliminieren, haben als Ziel, ein möglichst gleichmäßiges rosa Spektrum zu erreichen und die Fehler durch das plötzliche Einschalten des Sweeps zu verringern (deren Maß der Ripple ist, Stichwort: zeitbegrenzte Signale und ihr Spektrum). Bessere Erfolge verspricht da im übrigen die Erzeugung des Sweeps im Spektralbereich, die ist aber komplizierter und dauert erheblich länger, gerade bei langen Sweeps.
Ich auch. Bei einem 85ms langen Sweep mit den oben angegebenen Start- und Endfrequenzen liegen die Impulsantworten von K1 und K2 gerade einmal 20ms auseinander, das ist schon ziemlich eng. Für eine elektrische Messung ist das OK, aber bei einer akustischen, wo es Raumreflektionen gibt, wird das sicherlich zu knapp. Außerdem erhöhst Du mit einem längeren Sweep die SNR. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#24
erstellt: 26. Aug 2006, 13:19
|
|||||||||||||
|
Manches erscheint auf den ersten Blick schlechter als man denkt. Was eventuell auch daran liegen mag, dass man einen grundsätzlichen Fehler begangen hat Da habe ich mal eben - ich gebe zu, ich hatte schon vorgearbeitet - versucht, die Sweeps im Frequenzbereich zu erzeugen. Das ist mir vorher nie so ganz richtig gelungen, teils aus Leseschwäche, teils aus eigener Blödheit. Jedenfalls funktioniert das erstaunlich gut, der Code ist zwar komplizierter und es dauert auch etwas länger als die Erzeugung im Zeitbereich, aber es geht. Und zwar richtig gut, ganz entgegen meiner bisherigen Meinung. Und dann habe ich auch mal - um einen Vergleich zum rosa Spektrum zu erhalten - nochmals, obwohl der erste Versuch kläglich gescheitert war, einen Sweep mit weißem Spektrum benutzt. Die Ergebnisse sind gut, sehr viel besser als erwartet. Natürlich fällt die SNR im Bass etwas ab, aber sie ist immer noch hoch. Was bedeutet: man kann doch den Klirr mit konstantem Pegel messen. Natürlich mit der Einschränkung, dass der im Bass vielleicht etwas zu hoch ist (das ist er aber bei herkömmlichen Messungen auch!) Hier ein Bild zum Vergleich, die Grundwelle ist absolut identisch (schwarz), die Unterschiede in den Klirrkurven sind da, aber nicht dramatisch (da steht noch eine Serienuntersuchung zur Wiederholbarkeit der Messung aus). K2 ist blau (rosa Spektrum) und grün (weißes Spektrum). K3 rot (rosa S.) und magenta (weißes S.).  Eine Messung meiner Tröten schiebe ich gleich nach, die wird interessanter sein, gerade was die SNR angeht. So, da haben wirs schon. Farben wie vorher:  Man sieht sehr schön, wie das der "weiße" Sweep im Tiefton mit den Umgebungsgeräuschen zu kämpfen hat. Aber es ist noch akzeptabel. Man kann dort sicherlich mehr erreichen, indem man die Startfrequenz tiefer legt (hier 20Hz) und den Sweep länger macht. Das probiere ich gleich mal. Und die Vermutung hat sich vorerst nicht bestätigt. So, jetzt ist aber auch Schluss. Radio an, Fussball hören. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 26. Aug 2006, 13:32 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#25
erstellt: 26. Aug 2006, 15:53
|
|||||||||||||
|
Noch kurz an Guido: so wie Du den Sweep abspielst und wieder aufnimmst kann das nicht funktionieren. Das Messsystem steht und fällt mit der richtigen zeitlichen Verteilung der Frequenzen im Sweep (logarithmisch). Wenn im aufgenommenen Sweep aber ein Teil der tiefen Frequenzen erst nach den hohen kommt, dann passt das nicht mehr. Ich würde mal sagen dass genau daher diese Welligkeit kommt. Ich habe das Problem gelöst indem ich einfach länger aufnehme als ich bräuchte, bisher 1,5mal so lang wie der Sweep selber. Das scheint auszureichen, je nach Soundkarte und Messabstand kann es mehr oder weniger werden, es muss ja nur die Latenz überwunden werden. --- Der nächste Job wäre, die Phase vernünftig zu berechnen. Dabei stehe ich im Moment vor ein paar Problemen: - durch die allgegenwärtige Latenz schmuggelt sich dort ein Allpass hinein. Viele Messprogramme errechnen die Phase über die Hilbert-Transformation aus dem Amplitudengang, das gilt aber nur für minimalphasige Systeme, ein Lautsprecher ist das nicht, deswegen darf man das eigentlich nicht machen. Erschwerend kommt hinzu, dass die Latenz durch die Soundkarte schwankt, man kann sie also nicht einfach errechnen durch Latenz Soundkarte+Latenz Messabstand (<- diese ist berechenbar). Eine Lösung wäre eine Zweikanalmessung, die aber zusätzlichen mathematischen Aufwand bedeutet. Dabei wäre ein Kanal durchverbunden, der andere an den Lautsprecher angeschlossen. Vermutlich die sauberste Lösung, aber die Berechnungszeit verdoppelt sich. Eine andere Idee wäre: durch die Hilbertransformation den minimalphasigen Anteil des Frequenzganges ermitteln, dadurch lässt sich der allpasshaltige Teil extrahieren, und dann kann man ausnutzen, dass die Latenz eine linear fallende Phase erzeugt, und jede Abweichung von dieser Geraden sollte dann der allpasshaltige Teil des Lautsprechers selber sein. Genial, oder? (Aber ich weiß nicht, ob das funktioniert, die Idee ist mir vorhin gekommen). - das nächste Problem: die beiden atan()-Funktionen aus der math.h erzeugen PI-symmetrische Werte, also nur welche aus dem Bereich -PI bis +PI. Das ist äußerst ärgerlich, weil man so keine stetige Funktion erhält, sehr störend beim Glätten und auch bei weiteren Berechnungen. Da muss ich auch noch ein wenig Hirnschmalz reinstecken. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#26
erstellt: 26. Aug 2006, 19:04
|
|||||||||||||
Hmm, könnte sein, daß die Sprungstelle von Fo nach Fu im Sample stört, aber: 1. Die Bilder oben entstanden durch eine 2-Kanal Messung nach anschließender Kreuzkorrelation. Also aus der Impulsantwort. 2. Die Welligkeit scheint von der Aussteuerung abhängig zu sein. Verringere ich die Wiedergabelautstärke, verringert sich auch die Welligkeit (Verstärker?) Der Sweep ist schon deutlich energiereicher. Ich habe das z.B. daran bemerkt, daß die Resonanzfrequenz des 17ers um 10% niedriger liegt als bei Rauschsignalen! 3. Die Wellen treten anscheinend nur bei Messungen mit 4 kHz Abtastrate auf (Soundkarte?) 4. Bei Messungen mit Pink- und Whitenoise habe ich auch eine minimale Welle bei 50 Hz festgestellt (minimaler Netzbrumm?) 5. Wenn ich nicht die komplette Impulsantwort, sondern nur 90% davon auswerte, ist die Kurve glatt. Irgendwo um 91% der Impulsantwort tritt die Welligkeit auf. Im Plot der Impulsantwort ist dort aber nichts auffälliges zu erkennen. Irgendwie seltsam
Sowas hatte ich früher auch mal probiert. Da ich aber verschiedene Meßsignale zur Verfügung stelle, gab's bei manchen Probleme mit diesem Verfahren.
So mache ich es halt Bei 4096 Samples auch kein Performance-Problem. Bei deinen langen Aufnahmezeiten könnte es sich schon bemerkbar machen.
Sorry, zu hoch für mich (ich weiß z.B. nicht, was eine Hilberttransformation macht) 
Das ist ein bekanntes Problem, über das ich mir auch schon den Kopf zerbrochen hatte. Ist bei ARTA u.a. aber auch so. Dort gibt es aber die Möglichkeit der Minimum Phase und der Gruppenlaufzeit. Das wollte ich bei mir auch immer mal einbauen. Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#27
erstellt: 26. Aug 2006, 21:06
|
|||||||||||||
Achso, ich dachte Du hättest das Prinzip der Entfaltung benutzt. Mit einer Kreuzkorrelation ist das so natürlich möglich. Allerdings verlierst Du auch den Vorteil der Trennung von den Verzerrungen. Gilt der Zusammenhang KKF(Eingang, Ausgang)=IR nicht nur für weiße Eingangsspektren? Oder erschlägst Du das durch die Zweikanalmessung? Jedenfalls, da Du eine andere Auswertungstechnik benutzt:
Soundkarte. Vielleicht finde ich das Bild wieder, wo ich mal aufgenommen hat, was eine übersteuerte Soundkarte aus dem Sweep macht. Natürlich ist auch der Verstärker denkbar, wenn Deine Soundkarte über jeden Zweifel erhaben ist.
Auch möglich. Soundkarten arbeiten intern mit einer festen Samplingrate, und auf die wird gnadenlos resampled. Der dafür notwendige SRC scheint manchmal sehr minderwertiger Qualität zu sein, wie z. B. in meiner Soundkarte, die nur mit 44,1kHz vernünftig läuft. Der SRC erzeugt hier deutlich hörbare Artefakte!
Ja, denkbar. Der müsste allerdings mit rosa Rauschem weniger Einfluss haben als mit weißem Rauschem (gleicher Pegel bei 50Hz vorrausgesetzt)
??? Ich hätte im ersten Moment auf eine interne Reflektion in der Soundkarte getippt (ja, es gibt nichts was es nicht gibt) aber das müsste in der IR sichtbar sein.
Die Hilbertransformation ist keine Transformation, sondern ein Filter, und erzeugt aus einer reellen Funktion deren Analytische. Braucht eigentlich kein Mensch , aber mit ihr ist es möglich, aus dem Amplitudengang den Minimalteil des Phasenganges zu ermitteln. Die beiden - Amplituden- und Phasengang - hängen bei minimalphasigen Systemen direkt zusammen. Schau bei der Wikipedia nach, da steht was über den Hilbert. Gute Nacht Cpt. |
||||||||||||||
|
gundi
Stammgast |
#28
erstellt: 26. Aug 2006, 23:29
|
|||||||||||||
Soweit bin ich noch nicht. Da muß ich mich noch durchkämpfen . Außerdem weiß ich noch nicht, wie ich das logisch in mein Programm einfügen könnte.
Gilt bei der 2-Kanalmessung im Prinzip für jedes Signal. Bei einem reinen Sinus hättest du natürlich hauptsächlich Rauschen im Spektrum. Ein Frequenzbereich, der nicht angeregt wird, läßt sich schlecht vergleichen
So ist es, leider  Scheint mir jedenfalls EIN Hauptverdächtiger zu sein.
Nix zu sehen. Ich müsste mal eine Zoomfunktion einbauen Aber die ca. 90%-Stelle in der Impulsantwort ist ungefähr dort, wo im aufgenommenen Sweep der Wechsel vom 1. zum 2. Teilsweep erfolgt (also der Sprung von Fmax direkt auf Fmin). Im Link aus einem früheren Beitrag kann man die Stelle ja wunderschön sehen: http://ggebler.onlinehome.de/lsm-w32/Sweep3.jpgAber eine praktikable Lösung, diesen Sprung zu vermeiden, ist mir noch nicht eingefallen. Vielleicht eine Fensterfunktion am Anfang und am Ende des jeweiligen Teilsweeps, damit der Übergang sanfter erfolgt? Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#29
erstellt: 27. Aug 2006, 16:17
|
|||||||||||||
Wichtigste Vorraussetzung: Verzicht auf die 4k-Grenze. Ansonsten steht Dir der Quellcode offen.
OK.
Jupp. Schau mal, was eine Samplingrate von 48kHz aus einer Messung macht:  Die Buckel in den Harmonischen passen ungefähr zeitlich mit den hörbaren Artefakten zusammen, so PI*Daumen
Das würde den Sprung auf jeden Fall entschärfen. Ich würde Dir auch empfehlen, die neue Sweepgenerierung zu verwenden, ich werde gleich den Sourcetree aktualisieren, dann ist die perfekt (mit Callback-Funktion um dem Sweep einen eigenen Amplitudengang zu verpassen. Die Idee ist mir heute Morgen gekommen, nebenbei hab ich so auch das Prinzip der Callbacks kapiert ). Mit ein wenig Anpassung sollte das bei Dir auch einwandfrei funktionieren. Die Funktion heißt noch gen_sweep_new(), das wird sich bei Gelegenheit ändern. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 27. Aug 2006, 16:23 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#30
erstellt: 27. Aug 2006, 18:39
|
|||||||||||||
OK, ich habe jetzt erstmal auf 8192 Punkte aufgestockt
Ich habe mal ein sin^2-Fenster auf die ersten und letzten 164 Werte des Sweeps (je 1/50-tel des sweeps) angewendet: http://ggebler.onlinehome.de/lsm-w32/sweep48k.pngDer Übergang ist nun recht sauber und das Spektrum zu höheren Frequenzen hin schön glatt. Bei tiefen Frequenzen hat's natürlich wenig Auswirkungen. Bei weiteren Versuchen ist mir aufgefallen, daß die Welligkeit zwischen 50 und 100 Hz bei der 4 kHz-Messung wohl doch auf einen 50Hz-Brumm des Verstärkers zurückzuführen ist. Wenn ich in der Impulsantwort nur den Bereich hinter dem Impuls auswerte, sieht man es deutlich im Spektrum: http://ggebler.onlinehome.de/lsm-w32/sweep4k.pngWenn ich direkt vom Soundkarten-Ausgang zum Soundkarten-Eingang messe, sind diese Peaks nicht da. Und bei der 48 kHz-Messung ist die Frequenzauflösung wohl zu gering, sodaß der Brumm nicht weiter auffällt.
Prima! Schaue ich mir mal an. Gruß Guido [Beitrag von gundi am 27. Aug 2006, 18:42 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#31
erstellt: 28. Aug 2006, 21:19
|
|||||||||||||
Mathematisch ist die Sache einwandfrei: man nehme ein allpasshaltiges System (ein Teil des Allpasses durch die Latenz): H(jw)=A(jw)*e^(-j*PI*t(jw)), A(jw) sei der Amplitudengang Dann lässt sich der minimalphasige Anteil mit Hilfe der Hilbert-Transformation aus dem Amplitudengang ermitteln: H(jw)=A(jw)*e^(-j*PI*t_min(jw))*e^(-j*PI*t_all(jw)) Es interessiert jetzt mal nur der letzte Teil. Der ließe sich, unter Ausnutzung, dass eine Totzeit (Latenz) eine linear fallende Phase erzeugt, aufspalten: e^(-j*PI*t_all(jw))=e^(-j*PI*t_tot)*e^(-j*PI*t_ls(jw)) dabei ist t_ls(jw) der allpasshaltige Teil, der vom Lautsprecher stammen muss, t_tot die konstante Latenz. Verflucht, das ist so einfach, da muss es einen Haken bei geben. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#32
erstellt: 29. Aug 2006, 10:22
|
|||||||||||||
|
Hallo Jochen,
Ja, ganz easy! Ich habe mir deine Sourcen jetzt mal etwas näher angeschaut. Deine Sweep-Generierung im Frequenzbereich für mein Programmm umzusetzen ist mir vorläufig zu kompliziert. Zum Testen reicht mir erstmal die Generierung im Zeitbereich. Aber vielleicht wärst du so lieb, mir mal in Kurzform die Ermittlung der Impulsantworten für die Harmonischen zu erklären? Ich beschreibe mal kurz meine derzeitige Vorgehensweise: (N = Anzahl der gemessenen Samples) 1) Erzeugung eines Sweeps der Länge N, an den Enden "gefenstert" (für sanftes Ein- und Ausblenden) 2) Diesen Sweep kopiere ich 2-mal hintereinander in einen Ausgabebuffer der Länge 2N 3) Wiedergabe und Aufnahme (Länge N, 2-Kanal) 4) Jetzt habe je einen kompletten Sweep (wenn auch zeitlich verschoben, durch Latenzen oder Schallaufzeiten) für das Ein- und Ausgangssignal des DUT (z.B. Lautsprecher). 5) Jetzt kommt die Kreuzkorrelation im Frequenzbereich, die deiner Deconvolve()-Funktion verdächtig ähnelt: a) fft-buffer der Länge 2N jeweils für Referenz- und Antwortsignal reservieren b) fft für beide Signale ausführen c) komplexe Division über die gesamten 2N-fft-buffer durchführen (=> H = S/R mit der Länge 2N) d) ifft der Länge 2N für H ausführen e) Das Ergebnis enthält in den ersten N-Punkten die Impulsantwort des DUT. Was befindet sich eigentlich in den zweiten N Punkten nach der ifft? Nur Müll? Wenn ich es richtig sehe, ist deine Vorgehensweise bis hierhin ähnlich. Bei dir geht's dann so weiter (bitte korrigieren, falls ich falsch liege): - Lage der Impulsantworten der Harmonischen ermitteln (dist_inx()) - Die einzelnen Impulsantworten in separate Felder kopieren (kn_ir[i]=extract_ir()) - Dann die Spektren dieser Impulsantworten mittels fft_polar() ermitteln? Könntest du diese drei Funktionen bitte kurz erläutern? Mir ist halt immer noch nicht klar, wo und wie ich diese Impulsantworten finde und wie ich sie dann auswerte. Oder ist fft_polar() auch nur eine normale fft mit anschließender Berechnung von Betrag und Phase? Gruß und Danke schonmal, Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#33
erstellt: 29. Aug 2006, 11:55
|
|||||||||||||
|
Moin,
Denkfehler bei mir. Dazu später mehr.
Richtig.
Ich nicht. Ich nehme halt einfach "zu lange" auf.
Zwingend notwendig.
Ich sehs grade. Aber warum? Eigentlich müsste es eine komplexe Multiplikation (mit einem Teil komplex konjugiert) sein. Wobei es beim Einsatz einer MLS egal ist: sowohl Kreuzkorrelation als auch Entfaltung kommen auf das gleiche Ergebnis, die Impulsantwort des gemessenen Systems. Ich würde jetzt mal sagen: automatische Fehlerkompensation. Noch besser, durch diesen Fehler in der KKF ist die Sweep-Messung erst ermöglicht worden
Bis dahin war alles richtig. Jetzt natürlich die berechtigte Frage: was steckt da alles drin? Zuerst einmal natürlich die Impulsantwort, ohne Verzerrungen. Und am anderen Ende, von hinten beginnend, die Impulsantworten von K2, K3, ..., KN. Zur Erklärung mache ich am besten mal ein kleines PDF fertig.
Richtig, die heißt jetzt zur besseren Erklärung anders ( kn_index()). Das ist eigentlich nur eine Hilfsfunktion, die zusammen mit extract_ir() einen Teil der durch die Entfaltung errechneten "Gesamt-Impulsantwort" herausschneidet. Eigentlich macht die nichts anderes, als den Index zu errechnen, wo die Impulsantworten der Verzerrungen liegen. Die Zeitdifferenz zur IR der Grundwelle errechnet sich nach: delta_t=T*ld(K)/ld(fstop/fstart) T sei die Dauer des Sweeps. Weil die Faltung mit dem Umweg über die FFT immer zyklisch ist, kann es passieren, dass die Verzerrungs-IRs nicht am Ende, sondern am Anfang der "Gesamt-IR" liegen. Deswegen gleicht die Funktion diesen "wrap-around" aus.
Richtig.
Genau. Nichts weiter. --- So, und nun zum oben erwähnten Denkfehler: die Latenz durch Soundkarte und Mikrofonabstand ist für mich völlig egal. Die wird durch das Ausschneiden der Impulsantworten vollständig eliminiert. Das einzige, was ich noch als Latenz drin habe, ist die "rise time", die ich vor jede Impulsantwort lege. Die IR der Grundwelle suche ich ja über die max_ir() heraus, und weil das Maximum ganz bestimmt nicht der Anfang ist, nehme ich ein paar Samples davor mit. Also muss ich diese "rise time" herausrechnen. Was natürlich das gleiche Problem wie vorher ergibt: wie bekomme ich nun den Phasengang des DUTs heraus? Ich weiß ja nicht, wo die IR wirklich anfängt. Und da haperts: wie bekomme ich aus einem beliebigen Phasengang den linearen Teil heraus? Wenn ich nur damals in numerische Mathematik mehr aufgepasst hätte! Gruß Cpt. P.S.: bei der Gelegenheit würde mich mal interessieren, wieso ich einen Phasengang mit positiver Steigung erhalte. Irgendwie wirft das mein ganzes Verständnis von der Systemtheorie durcheinander, es müsste doch eigentlich eine fallende Phase sein (Totzeit/Latenz bedeutet immer einen fallenden Phasengang). Hab ich da eventuell irgendwo ein "-" verschlampt? P.P.S.: in der Tat! es muss in der fft_polar() "-atan2(im, re)" heißen. Teufel, wie konnte mir das nur passieren? [Beitrag von Cpt._Baseballbatboy am 29. Aug 2006, 18:10 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#34
erstellt: 29. Aug 2006, 16:41
|
|||||||||||||
|
Hallo Jochen, vielen Dank für deine Mühe!
Ich habe es auch schon mit einem Sweep versucht, der kleiner N ist (ca. 85%) und diesen dann nur einmal abgespielt. Wenn die Laufzeit zum Mikro nicht zu lang ist (sonst rutscht er bei der Aufnahme hinten raus ), komme ich dann zwar zu ähnlichen Ergebinissen (Für Betrag und Phase), der Rauschabstand ist aber etwas schlechter.
Echt jetzt? Die KKF ist falsch?
Hat aber auch mit sämtlichen anderen Messsignalen funktioniert (Impuls, rosa und weisses Rauschen).
Also im Bereich N...2N-1 stecken die. OK, muß ich mir mal anschauen.
Das wäre natürlich Super!
Du meinst T*log10(N)/log10(fstop/fstart), oder? Mal kurz nachrechnen (N=8192, fstop=22000, fstart=60): => dt/T = 1,526 Das würde bedeuten, die Impulsantworten der Harmonischen würden bei mir z.Z. etwa in der Mitte des Bereichs N...2N-1 liegen? Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#35
erstellt: 29. Aug 2006, 17:36
|
|||||||||||||
Ja. Die Kreuzkorrelation, im Frequenzbereich durchgeführt, entspricht der Faltung, nur mit dem einem Operanden konjugiert komplex. Such mal bei Google nach "fft correlation".
Genau das wollte ich damit sagen. Du machst da ja nichts anderes als das Spektrum des gemessenen Signals durch das Referenzspektrum zu teilen, das Ergebnis ist die Übertragungsfunktion des DUT. Und die IFFT von der ergibt nunmal die IR.
Nicht unbedingt. Im Normalfall schon, aber das muss nicht. Deswegen kompensieren das meine Funktionen.
Natürlich. Den Logarithmus im Zähler habe ich unterschlagen. Genauer wäre es, den logarithmus dualis einzusetzen, weil der auch bei der Sweeperzeugung zum Einsatz kommt. Das Ergebnis ist aber das gleiche.
N ist hier die Ordnung der Harmonischen, also 2, 3,... Am besten, ich ändere das um in K. Dann ist das eindeutiger. K2 würde fast genau 20ms vor K1 liegen, K3 31,7ms. Das ist schon ziemlich knapp, wenigstens K3 würde in K2 hereinfunken, das sind immerhin nur 11,7ms Unterschied. Deswegen braucht es entweder einen langen Sweep oder Du nimmst einen kleineren Frequenzbereich. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#36
erstellt: 29. Aug 2006, 19:35
|
|||||||||||||
|
So, habe mal kurz ein Stündchen Schlaf nachgeholt
Genau das, dachte ich bisher immer, wäre Sinn und Zweck einer Kreuzkorrelation. Naja, Hauptsache es funktioniert Nenne ich die Funktion halt um.
Achso, verstehe!
Verstehe. Das heisst aber dann auch, daß bei großen Delays zwischen Ausgabesignal und Antwort des DUT (lange Schalllaufzeiten bei großem Mikrofonabstand), der Impuls von k2 am Anfang der sichtbaren Impulsantwort (0...N-1) auftauchen würde? Aber ich denke sowieso darüber nach, fstart höher anzusetzen (~200 Hz, => k2 bei -25ms, k3 bei -40ms), da 1) in normalen Wohnräumen sowieso nicht tieffrequenter reflexionsfrei gemessen werden kann 2) so ein Sweepsignal doch recht kräftig ist. Das könnte einem Hochtöner ohne Weiche ziehmlich weh tu'n Hier mal ein Bild mit einer Sweepmessung von Soundcard-Out nach Soundcard-In (Loopback): http://ggebler.onlinehome.de/lsm-w32/sweep48k-2.pngGezeigt ist der Bereich N...2N-1 nach der KKF (Sorry, Deconvolve()), wo also die Impulse Kx liegen sollen. Sieht irgendwie komisch aus, oder? Die Werte sind auch sehr klein (max 3e-17!). Das wären -330dB bezogen auf den Hauptimpuls! Wäre ja toll, wenn's stimmen würde Ergo: Irgendwas läuft noch falsch. Gruß Guido /* edit */ Noch'n Bild: http://ggebler.onlinehome.de/lsm-w32/sweep48k-3.pngDiesmal habe ich das Eingangssignal (Antwortsignal) mal direkt mit dem erzeugten Sweep im Speicher (also unter Umgehung der Soundkarte) "verconvoltiert". Das sieht schon eher nach Impulsen aus. Insgesamt finde ich einen kräftigen Impuls (im Bild zu sehen) und 2-3 relativ kleine Impulse weiter rechts (inverse Zeitdarstellung, links t=0, rechts t=-171 ms). Scheint wohl keine gute Idee zu sein, den rechten Ausgabekanal als Referenz herzunehmen um den linken Kanal zu messen [Beitrag von gundi am 29. Aug 2006, 21:26 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#37
erstellt: 30. Aug 2006, 07:32
|
|||||||||||||
Das kann passieren.
Warum nicht. Musst Du dann ausprobieren wieviel Fehler das produziert. Die Erfahrung hat gezeigt das man dann ungefähr eine Oktave wegschmeißen kann (also erst bei 400Hz vernünftige Werte erhält).
Das ist richtig, Reflexionen werden so etwas unterdrückt. Übrigens sind die, genau wie bei MLS, sichtbar und können herausgeschnitten werden.
Mir ist das mal bei der ursprünglichen Projektarbeit passiert. Da hab ich einem kleinen 19er HT einen Sweep ab 20Hz verpasst, und zwar mit Schmackes. Ich dachte, das Ding raucht ab. Es roch auch ein bisschen streng. Aber er hats überlebt. War aber eh als defekt markiert.
Du hast ne gute Soundkarte
Denke ich auch.
Ist der große jetzt K1 oder einer der Verzerrungen? Die beiden kleinen Spitzen kommen mir noch eigenartig vor, die Abstände zwischen dem Hauptimpuls und den beiden scheinen mir konstant zu sein. Dann können die eigentlich nichts mit den Verzerrungen zu tun haben. Oder schaue ich falsch? Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#38
erstellt: 30. Aug 2006, 12:46
|
|||||||||||||
|
Also, einen Fehler (?) habe ich mittlerweile gefunden. Und zwar mußte ich die Größe der FFT-arrays verdoppeln! Bei der Untersuchung deiner Deconvolve()-Funktion ist mir schließlich aufgefallen, daß du fft-arrays der Größe 2*N * sizeof(struct Complex) reservierst, d.h. 4*N*sizeof(double), da die Struktur Complex ja aus 2 Elementen (real und imag) besteht. Also benötige ich Arrays der Größe 4*N! Die Messdaten werden dann in das 1. Viertel des fft-Arrays kopiert (Rest =: 0). Nach fft, komplexer Division und ifft befinden sich im 1. Viertel des Arrays die Impulsantwort k1 und im 2. Viertel sollten sich dann eigentlich die Impulse für k2...kn befinden. Soweit richtig? Leider empfinde ich die Daten im 2. Viertel immer noch nicht als eindeutig. Evtl. liegt's am Messaufbau Man bräuchte mal ein synthetisches Signal (aus dem Sweep generiert) mit bekanntem k2/k3-Anteil, die ich dann mal miteinander deconvolven kann. Kennst du da was? Aber immerhin sieht die 1. Impulsantwort (k1) schonmal viel besser aus und die Impedanzmessung mit 4 kHz (wo ja vorher diese komischen Wellen drin waren) ist nun auch einwandfrei und deutlich besser als Vergleichsmessungen mit MLS oder Rauschsignalen! Gruß Guido Achja: Außerdem bin ich wieder auf die einmalige Wiedergabe eines kürzeren Sweeps (Länge 0.9*N) umgestiegen. Bei meinem alten Verfahren (zweimalige Wiedergabe eines Sweeps der Länge N) landen die tiefen Frequenzen bei der Aufnahme ja zeitlich hinter den hohen Frequenzen. Das heisst doch, daß deren Phasenverschiebung sehr groß ist und es sich bei den aufgenommenen Daten eigentlich nicht mehr um einen log. Sweep handelt, wie wir ihn für die Messung der harmonischen Verzerrungen brauchen. Oder irre ich mich da? [Beitrag von gundi am 30. Aug 2006, 12:58 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#39
erstellt: 30. Aug 2006, 13:16
|
|||||||||||||
|
Hmja, Du hast ja eine etwas andere Anordnung der Real- und Imaginärteile, ich glaube halb-komplex heißt die. Das musst Du also dementsprechend anpassen. Also immer die doppelte Anzahl wie bei mir verwenden. Ich würde Dir auch empfehlen, statt malloc() calloc() zu verwenden, weil der Speicherbereich danach immer mit 0 initialisiert ist. Das ist zwar nicht unbedingt nötig, wenn Du den Speicher danach selber vollständig initialisierst, aber es vermeidet manch ungewollten Fehler. Übrigens ist die deconvolve() gar nicht so weit von einer KKF entfernt. Eine Faltung im Frequenzbereich sieht so aus: A(w)xB(w), also ganz normale komplexe Multiplikation. Eine KKF wäre: A(w)xB*(w), wobei der Stern komplex-konjugiert bedeutet. Die "Entfaltung" ist nichts anderes als eine Faltung, bei der der zweite Operator invertiert ist, also: A(w)x1/B(w) Daraus wird: A(w)/B(w) = A(w)xB*(w)/|B(w)| Die Entfaltung ist also, bis auf den Nenner, identisch mit der KKF, für weiße Spektren - dann wäre |B(w)|=1 sind sie es sogar vollständig. Der Vorteil an der Entfaltung ist natürlich die Möglichkeit, auch nicht-weiße Spektren einsetzen zu können. Edit:
Das vermute ich. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 30. Aug 2006, 13:17 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#40
erstellt: 30. Aug 2006, 14:02
|
|||||||||||||
Ah, Danke! Jetzt verstehe ich endlich, warum meine "KKF()" mit allen Signalen funktioniert hat. Weil's eigendlich eine Entfaltung ist! Edit:
Was vermutest du? Daß ich mich irre? Gruß Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#41
erstellt: 30. Aug 2006, 14:25
|
|||||||||||||
Ääähh... Das die Art der Aufnahme des Sweeps mit den tiefen Frequenzen hinten nicht richtig funktionieren kann. Gruß Cpt. |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#42
erstellt: 31. Aug 2006, 10:11
|
|||||||||||||
Dieses kam mir doch äußerst verdächtig vor. Konnte ich nicht mehr mit komplexen Zahlen rechnen? Eine kurzfristig anberaumte Untersuchung ergab: es gehört kein "-" vor atan2(), ich hatte schlicht und einfach in der fft() und ifft() ein Minus mit einem Plus vertauscht - mit dem Ergebnis, dass die ifft() die fft() ausgeführt hat und umgekehrt. Wär mir ja schneller aufgefallen, wenn die beiden Transformationen sich nicht so grundsätzlich ähneln würden. --- Womit ich auch nochmals auf die Messung der Phase zurückkommen möchte. Das ist nämlich alles andere als trivial. Das Extrahieren der Latenz aus einem gegebenen Verlauf ist - zumindest was meine mathematischen Kenntnisse angeht - mit den gegebenen Vorraussetzungen nicht möglich. Empfohlene Vorgehensweise: die IR möglichst knapp vor ihrem Beginn ausschneiden. So macht es ARTA - laut Handbuch - auch. Zusätzlich werde ich noch eine Funktion zum Ermitteln des minimalphasigen Anteils implementieren. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 31. Aug 2006, 10:15 bearbeitet] |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#43
erstellt: 01. Sep 2006, 13:16
|
|||||||||||||
Kein Problem: nimm einfach den Sweep und multipliziere jedes Sample mit a*x+b*x²+c*x³. a, b, und c müssen nur der Bedingung a²+b²+c²=1 genügen, und der Sweep darf maximal bis (fs/2)/3 gehen, sonst gibts Aliasing, aber nicht zu knapp. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#44
erstellt: 01. Sep 2006, 14:34
|
|||||||||||||
|
Hmm, und wofür steht x in dieser Formel? |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#45
erstellt: 01. Sep 2006, 16:13
|
|||||||||||||
|
Für jedes Sample. Gruß Cpt. [Beitrag von Cpt._Baseballbatboy am 01. Sep 2006, 16:13 bearbeitet] |
||||||||||||||
|
gundi
Stammgast |
#46
erstellt: 01. Sep 2006, 17:58
|
|||||||||||||
|
OK, Danke! Ich hab's mal mit folgender Formel probiert: x[i] = 0.99*x[i] + 0.122*x[i]*x[i] + 0.0708*x[i]*x[i]*x[i]; Der Sweep sieht im Zeitbereich zwar etwas seltsam aus (hoher DC-Anteil?), aber die Impulse für k2 (rechts) und k3 (links, markiert) sind deutlich zu sehen. Wenn auch etwas durch Aliasing verseucht (Sweep bis fs/2). http://ggebler.onlinehome.de/lsm-w32/sweep48k-6.pngWie man sieht, liegt k3 bei ca. -35dB (k2 bei ca. -24dB). Die Impulse liegen bei ca. -20ms (k2) und -32ms (k3) Bei einer Sweeplänge von 157 ms (fstart = 99,6 Hz, Fstop = 24000 Hz) passt das ganz gut mit den Berechnungen überein (-19,8 ms bzw. -31,5 ms) Sieht das für dich OK aus? |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#47
erstellt: 02. Sep 2006, 12:22
|
|||||||||||||
|
Sieht prima aus. Ich weise mal daraufhin, dass das Aliasing kein Problem darstellt, wenn normal gemessen wird, weil dann die zu hohen Frequenzen durch den Eingangstiefpass der Soundkarte herausgefiltert werden. Gruß Cpt. |
||||||||||||||
|
gundi
Stammgast |
#48
erstellt: 02. Sep 2006, 14:40
|
|||||||||||||
Na gut!
Ist klar. Hoffentlich verschwinden die Wellen im unteren Frequenzbereich dann auch weitestgehend. Jetzt könnte ich also langsam damit anfangen, die automatische Berechnung der Klirrspektren in's Programm einzubauen. Dazu sind aber einige Änderungen am Programm notwendig und mein Urlaub ist am Montag auch zu Ende. Mal schauen, wie ich weiterkomme Bis dann! Guido |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#49
erstellt: 08. Sep 2006, 19:30
|
|||||||||||||
|
Moin, letztes Wochenende habe ich den Quellcode ein wenig umstrukturiert und dabei eine wichtige Lektion gelernt: manchmal ist simples copy & paste von bekanntermaßen funktionierenden Sachen besser als abtippen. Denn plötzlich kam Mist heraus. Warum auch immer. Ich hatte nichts anderes gemacht, als die eigentliche Entfaltung aus der bisherigen Funktion deconvolution() auszugliedern und der neuen Funktion diesen Namen zu geben, die alte heißt nun calc_response(). Der Grund war einfach eine gesteigerte Flexibilisierung der API. Und dort habe ich einen Fehler gemacht. Multipliziert man zwei komplexe Zahlen X und Y miteinander, so ergibt sich Z nach: Re(Z)=Re(X)*Re(Y)-Im(X)*Im(Y) Im(Z)=Re(X)*Im(Y)+Im(X)*Re(Y) Und bei mir stand: Re(Z)=Re(X)*Re(Y)-Im(X)*Im(Y) Im(Z)=Re(X)*Im(Y)+Re(X)*Re(Y) Na, wer siehts? Wenn ich statt die Formeln neu zu tippen einfach ein C&P aus der bisherigen deconvolution() gemacht hätte, wäre dieser Fehler niemals passiert. Ich habe dafür von Samstag bis Mittwoch gebraucht. Ich dachte schon, ich hätte alles verbockt, weil die auf dem CVS-Server liegenden Sourcen - die eigentlich hätten funktionieren müssen - noch mehr Schrott verursacht haben (warum? keine Ahnung, ist auch egal). Jedenfalls geht es jetzt wieder, nebenbei ist noch eine in-place-fft hinzugekommen, die an einigen Stellen eine Menge Speicher spart (den ich anderer wieder durch den gnadenlosen Einsatz von complex-2-complex-ffts sinnfrei verschwende aber das macht den Code so einfach )Gruß Cpt. P.S.: Hat jemand Lust ne kleine Webseite zu entwerfen? Muss nichts dolles sein, nur ein Grundgerüst. Mir fehlt da im Moment die Zeit und noch mehr die Motivation... [Beitrag von Cpt._Baseballbatboy am 08. Sep 2006, 19:52 bearbeitet] |
||||||||||||||
|
Arlon
Ist häufiger hier |
#50
erstellt: 21. Sep 2006, 18:31
|
|||||||||||||
|
Webseite? - warum nicht... mail mir mal, was du da alles drauf haben willst.. Gruss Stefan |
||||||||||||||
|
Cpt._Baseballbatboy
Inventar |
#51
erstellt: 29. Sep 2006, 18:24
|
|||||||||||||
|
Leider fehlt mir in den letzten Tagen ein wenig die Zeit, viel an dem Projekt weiterzuarbeiten. Dennoch habe ich versucht, es auf OpenBSD zu übertragen. An der Implementierung der Audioausgabe und -aufnahme ist das leider gescheitert. Wobei ich jetzt nicht weiß, ob das am Programm oder an der Soundkarte in meinem Notebook liegt. Angeblich kann die full-duplex, das ist zumindest die Grundvorraussetzung für eine erfolgreiche Funktion des Programms. Desweiteren habe ich heute eine Programmbibliothek "entdeckt", mit der es möglich ist, schnell und einfach Bilder zu erstellen. Heißt, ich könnte in relativ kurzer Zeit eine Ausgabe in grafischer Form zaubern. Finde ich einen interessanten Weg, so spart sich eine Menge GUI-Gelumpe, einfach ein Bild schreiben und das kann sich der geneigte Messdiener dann anschauen. @Arlon: ich hatte noch mit einer Antwort gewartet, weil schon wer anderes Interesse hatte. Dem fehlt aber die Zeit dazu. Hast Du noch Interesse? Ich bräuchte nichts kompliziertes, ganz einfach mit Navigationsleiste und Hauptframe, in dem dann Doku, Theorie und Neuigkeiten angezeigt werden. Vor allem brauche ich keinen Schnickschnack so wie Javascript oder noch schlimmer, Flash  Solche Seiten rangieren bei mir persönlich ganz weit unten auf der Beliebtheitsskala, da seh ich nicht ein, warum eine von mir betrieben Seite sowas machen muss. Gruß Cpt. |
||||||||||||||
| ||||||||||||||
#1
erstellt: 06. Aug 2006, 
|
|
||||
| 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 |
|
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 |
|
Maximale Auslenkung eines Lautsprecher Parday am 15.03.2019 – Letzte Antwort am 29.03.2019 – 20 Beiträge |
|
Fügen von Messungen mit Bassreflexport auf der Rückseite MK_Sounds am 01.09.2017 – Letzte Antwort am 24.03.2018 – 4 Beiträge |
|
LS Simulationsprogramm sandscholle am 30.01.2014 – Letzte Antwort am 30.01.2014 – 2 Beiträge |
|
ARTA THD Messung eines Verstärkers telosvisor am 14.04.2021 – Letzte Antwort am 16.04.2021 – 2 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 |
Foren Archiv
2015
Anzeige
Produkte in diesem Thread
Aktuelle Aktion
Partner
Top 10 Threads der letzten 7 Tage
- Hotel Modus deaktivieren
- "diese anwendung wird jetzt neu gestartet um mehr speicherplatz verfügbar zu machen"
- Von HD+ zurück zu Standard-TV
- Remotekabel anschließen, aber wie und wo?
- Hisense verbindet sich nicht mehr mit dem WLAN
- Audiodeskription ausschalten (in ZDF App) 803er
- Umschalten von TV auf Radio
- Satellitenschüssel was und wie einstellen am TV
- Pro 7 und Sat 1 auf einmal weg.
- Markierung an Lautsprecherkabel - welche Norm?
Top 10 Threads der letzten 50 Tage
- Hotel Modus deaktivieren
- "diese anwendung wird jetzt neu gestartet um mehr speicherplatz verfügbar zu machen"
- Von HD+ zurück zu Standard-TV
- Remotekabel anschließen, aber wie und wo?
- Hisense verbindet sich nicht mehr mit dem WLAN
- Audiodeskription ausschalten (in ZDF App) 803er
- Umschalten von TV auf Radio
- Satellitenschüssel was und wie einstellen am TV
- Pro 7 und Sat 1 auf einmal weg.
- Markierung an Lautsprecherkabel - welche Norm?
Top 10 Suchanfragen
Forumsstatistik
- Registrierte Mitglieder927.515 ( Heute: 10 )
- Neuestes MitgliedHuPa
- Gesamtzahl an Themen1.555.834
- Gesamtzahl an Beiträgen21.646.474
