Entwicklung eines freien LS-Messprogramms

sehr interessantes unterfangen was ihr da habt.

ich kenne da einen der evlt froh um hilfe wäre

www.tomy-pa.de

evlt nach linux und mac protiren und ne tolle oberfläche gestalten so wie das

in der PA szene oft verwendete SMAART.


dazu die topmoderne LEQ messung mit einfliessen lassen von

www.dbmess.de

und alles wird gut.


ARTA macht ja gerade furore lohnt es da noch selbst zu tüfteln ?

tthorstenpa schrieb:

ARTA macht ja gerade furore lohnt es da noch selbst zu tüfteln ?

ARTA:

- kostet (in der Vollversion)
- läuft nur unter Windows
- hat nicht die geniale Verzerrungsmessung dieses Projektes

Deswegen lohnt es sich.

Gruß
Cpt.

Hi Cpt.

hmm, ich weiß garnicht ob ich mich trauen soll ... aber, wäre es eigentlich vorstellbar, das dein Programm auch auf Apple Rechnern, sprich Mac OS X läuft, iss doch eh alles Unix?

Naive Frage? ... kann wohl sein, meine Programmierkenntnisse beschränken sich auf Javascript und Flash (okay plus PHP und Html)

ps. Für eine Projekt-Webseite würde ich Movable Type nahe legen(personal edition = kostenlos) habe ich schon ein paarmal implementiert und ich finde es unschlagbar einfach und zuverlässig, auch von Noob's zu bedienen, ich würde evtl. helfen wenn's nötig ist.

mdh schrieb:

hmm, ich weiß garnicht ob ich mich trauen soll ... aber, wäre es eigentlich vorstellbar, das dein Programm auch auf Apple Rechnern, sprich Mac OS X läuft, iss doch eh alles Unix?

Portaudio läuft nach Angaben der Entwickler unter Mac OS 8-X, der Rest ist bisher alles in reinstem C verfasst, sollte also auch kein Problem sein.

Gruß
Cpt.

Hab heute ein Programm entdeckt, dass freie Software ist und genau diese Technik nutzt: http://gaydenko.com/qloud/

Es ist ebenfalls noch im Anfangsstadium, hat aber schon ein GUI (dafür nicht so ausgefeilte Algorithmen ). Läuft unter Linux, müsste aber auch unter FreeBSD funktionieren (kompilieren scheiterte heute, liegt aber wahrscheinlich an meiner etwas veralteten Version vom Qt-Toolkit).

Habe mich auch mit dem Entwickler schon in Kontakt gesetzt, ich werde da wohl einiges einfließen lassen. Dieses Projekt hier bleibt aber weiterhin bestehen.

@mdh: auch dieses sollte unter MacOS laufen, zumindest unter X. Ich habe im Code bisher nichts gesehen, was besonders plattformabhängig wäre. Audio-I/O geht über JACK, und das läuft laut Entwicklern unter X.

Gruß
Cpt.

Hi Cpt.

danke für die Antworten, klingt ja einerseits vielversprechend, andererseits aber auch nach einer Menge Tüftelei die Programme zum laufen zu bekommen - erstmal kompilieren kann man sicher alles lernen, wenn ich nur wüsste wo ich die Zeit hernehmen soll...

Ich werde das Thema "langsam" weiterverfolgen, mein Apple Powerbook wäre schon sehr gut zum Messen, fast völlig geräuschlos und ab Werk eine gute Soundkarte (THD+N=0.003) - wenn ich da mein PC Notebook im Job anschaue könnt ich k*tzen.

mdh schrieb:

andererseits aber auch nach einer Menge Tüftelei die Programme zum laufen zu bekommen - erstmal kompilieren kann man sicher alles lernen, wenn ich nur wüsste wo ich die Zeit hernehmen soll.

Ja, leider ist es am Anfang oftmals eine große Frickelei. Eine Menge Arbeit von Projekten besteht darin, sie für die verschiedenen Plattformen lauffähig zu machen. Denn ein Windows-Executable läuft nicht (ohne weiteres) unter Linux, und auch nicht umgekehrt. Eine Möglichkeit, dieses Problem zu umgehen, ist die Verbreitung des Programmes als Quellcode.

Gruß
Cpt.

Hi Cpt.,
wenn Du Lümmel mir nicht auf meine PN antwortest, dann petze ich das hier!

Audiounterstützung für OpenBSD ist fertiggestellt.

Nächster Halt: eine laufende Version unter Windows. Das hat jetzt Priorität.

Gruß
Cpt.

Nachdem mir Windows immer wieder dermaßen auf die Nüsse geht, wurde der Zug jetzt umgeleitet. Im Vordergrund steht jetzt ein schlüssiges Konzept, das ich mir letzte Woche unter der Dusche überlegt habe:

1.) das Basisprojekt wird ohne GUI existieren

2.) es wird in seine elementaren Bestandteile aufgespalten:

- Generierung des Sweeps
- Messung des Probanden
- Auswertung

Was bedeutet das?

Jeder dieser Punkte wird ein eigenes kleines Kommandozeilenprogramm. Der Sweep wird generiert und in eine Roh-Datei geschrieben, die nebenbei auch noch notwendige Informationen enthält.

Diese Datei wird vom Messprogramm eingelesen, der Sweep wird abgespielt und die Antwort des Systems aufgenommen. Das Ergebnis der Entfaltung (Sweep wird aus Antwort herausgerechnet) wird wiederum in eine Roh-Datei gespeichert.

Mit der Datei arbeitet dann das Programm zur Auswertung, die Ausgaben erfolgen dann in einem Text-Format, ausgerichtet auf Gnuplot.

Nebenher werden noch ein paar Tools entstehen, die z. B. die Rohdaten in eine WAV- oder Textdatei unmwandeln.

Wichtig ist die Skriptbarkeit der Programme, so dass Abläufe automatisiert werden können. Deswegen können die Namen der Dateien beliebig gewählt werden. Eine Messung des Frequenzgangs und der ersten beiden Oberwellen würde dann z. B. so aussehen (vorläufiges Konzept):

generate -o excitation.raw measure -i excitation.raw -o response.raw esweep -i response.raw -o test.txt harmonics k1 k2 k3 (hier könnte nun z. B. gnuplot mit der Datei test.txt und anderen Parametern aufgerufen werden)

Einige Mausschubser wird das sicher enttäuschen, aber denkt daran: eine GUI beschränkt Euch immer auf das, was der Entwickler vorgesehen hat (besonders was die Darstellung anbelangt). Mit diesem Konzept biete ich anderen die Möglichkeit, die Messdaten weiter zu verwerten, besser darzustellen, andere Berechnungen durchzuführen, usw.

Außerdem hab ich keine Zeit und Lust eine aufwändige GUI zu entwerfen. Das ist nämlich nen Haufen Arbeit wenns denn vernünftig werden soll.

Gruß
Cpt.

Hallo,

nettes Projekt. Denk bei der Entwicklung der einzelnen Teilprogramme bitte daran, die Funktionalität in eigene Bibliotheken zu packen. Dann kann man, wenn man Lust hat, eben doch mal leicht eine GUI drum herum basteln...

Grüße
Heiner

Hallo Cpt. / Guido,

bei Messungen der Nachhallzeit mit verschiedenen Programmen und Soundkarten (Direktmessung der Soundkarte) wird ein Nachhall zwischen 20 und 80 Hz von 400 bis 200ms angezeigt.

Was meint Ihr. Liegt der Fehler bei den Soundkarten, oder am Computer? Oder nutzen vielleicht viele Meßprogramme ähnliche oder gleiche Routinen, die diesen Fehler verursachen.

Die Nachhallzeit sollte ja bei Soundkarten immer fast 0ms betragen?


Gruß - Richard

Leider komme ich z. Z. nicht viel zu Arbeit an diesem Projekt, da sind zwei andere Dinge wichtiger.

Aber die beiden Posts will ich mal gerade beantworten:

@jaywalker:

natürlich.

@Richrosc:

Bei der Direktverbindung der Soundkarte sollte es natürlich überhaupt keinen Nachhall geben. Das es an den Algorithmen liegt mag sein, halte ich aber für unwahrscheinlich.

Eher glaube ich, dass Du da das Netz mitmisst.

Wie ist denn der Nachhall in den restlichen Frequenzbereichen?

Gruß
Cpt.

Hallo Cpt.,

folgendes Ergebnis habe ich gemessen.



Bei ARTA und Hobbybox sieht es ähnlich aus!

Gruß - Richard

Sieht wirklich eigenartig aus. Ich würde weiterhin auf Netzstörungen inkl. Oberwellen tippen.

Ein steiler Hochpass könnte zwar auch so etwas erzeugen, aber der ist nirgendwo sichtbar.

Gruß
Cpt.

Hallo Cpt.,

Ich würde weiterhin auf Netzstörungen inkl. Oberwellen tippen

Zwei weitere Forumnutzer, einer aus Dresden der andere aus Berlin bekommen mit CARMA fast die gleichen Ergebnisse.

Jedenfalls schade, da ich meine Raumakustik nicht weiter richtig messen kann.

Vielleicht hast Du ja mal Zeit und mißt, wie es bei Dir aussieht.

Gruß - Richard

Moin zusammen!
Nach längerer Abwesenheit hab' ich auch nochmal hier reingeschaut

@richrosc
Dieses Nachschwingen im Wasserfalldiagramm ist normal und liegt am Messverfahren:

Der Start des FFT-Fensters wird im Zeitbereich immer weiter nach hinten verschoben. Dabei kann es dann vorkommen, daß der Amplitudenwert des ersten Datenpunkts (wahrscheinlich auch folgender Datenpunkte) des Auswertbereichs nicht auf 0 liegt. Das Auswertsignal für die FFT ist dann nicht mehr periodisch sondern enthält praktisch einen Sprung am Anfang, der sich ähnlich wie ein Impuls auswirkt.
Außerdem wird das effektive FFT-Fenster i.d.R. immer mehr verkürzt, so daß die Frequenzauflösung mit der Zeit (Vordergrund des Wasserfalls) sinkt.
Abhilfe könnte evtl. die Verwendung einer Fensterfunktion bringen.

Eine andere Möglichkeit wäre, daß die Soundkarte einen kleinen Gleichspannungsoffset hat. Der wrikt sich dann ähnlich aus.

Ich hoffe, ich habe es einigermaßen verständlich beschrieben

---------

Ich habe vor kurzem meinen PC aufgerüstet (neues Mainboard mit core2duo E6300).
Das Board (Asrock 775Dual-VSTA) hat einen onboard Soundchip Realtek ALC880. Damit habe ich noch einige Probleme.
Frequenzgang und Rauschverhalten des ALC880 scheint recht brauchbar zu sein. Allerdings habe ich wieder mit enormen Latenzen zu kämpfen. Bei einer Direktverbindung Line-Out -> Line-In habe ich eine Totzeit von über 15 ms!.
Das heisst, das gemessene Ausgangssignal kommt erst 15 ms nach Aufnahmestart am Eingang an (bei gleichzeitigen Start von Aufnahme und Wiedergabe).

Ich komme wohl nicht drumrum, mal eine einstellbare Option zum Ausgleich von Latenzzeiten in mein Programm einzubauen, da es diesbezüglich wohl große Unterschiede zwischen verschiedenen Soundkarten gibt.


Gruß
Guido

Hallo Gundi,

danke für deine Infos.

Abhilfe könnte evtl. die Verwendung einer Fensterfunktion bringen.

Meinst Du, statt den Hanning- mal den Blackmanalgorithmus etc.?


Mit freundlichen Grüßen

Richard Schwab

Hallo,

Bei Sat-Live können im RTA Modus zwei Eingangskanäle paralell dargestellt werden.

Interessant dann, wenn das Eingangssignal der Qualle und der Eingangskanla des Mikro (Lautsprecher) verglichen werden soll.

Es ist jedoch schwierig zu beobachten, welche Unterschiede nun genau gemessen werden.

Ideal wäre nur eine Kurve, die lediglich die Pegeldifferenz aus beiden Kurven darstellt. Dann sähe man sehr einfach, auch beim abspielen von Musik, wie "falsch" der LS/Raum spielen.

Diese Funktion habe ich noch in keinem Programm entdecken können. Der dazugehörige Algorithmus kann doch eigentlich nicht kompilziert sein?

Gruß - Richard

Manchmal, da könnte ich mich...

Ich habe mich am Wochenende mal wieder dran getraut, weiter am Programm zu basteln.

Zuallererst stellte ich gestern fest, dass die Impulsantworten spiegelverkehrt sind. Das war mir nie aufgefallen, weil ich die ganze Zeit Soundkartenintern gemessen hab, und die hat eine symmetrische Impulsantwort (halt ein FIR-Filter). Erst als ich dann mal wirklich einen Lautsprecher gemessen habe kam mir das doch sehr eigenartig vor.

Die Ursache war schnell gefunden. Während der Entfaltung wird eine komplexe Division durchgeführt. Dort war ein Vorzeichen falsch, damit der resultierende Imaginärteil gespiegelt und das führt zu einer Zeitumkehr.

Viel gravierender war aber der Fehler, den ich dann entdeckte. Das besondere an dieser Messmethode ist, dass man ganz genau bestimmten kann, wo sich die Klirrkomponenten in der Impulsantwort befinden. Dazu muss man das Verhältnis zweier Logarithmen berechnen. Es ist aber fatal, wenn man im Nenner den natürlichen und im Zähler den 10er-Logarithmus verwendet...

Bis ich das herausgefunden habe vergingen Stunden. Ganz exakt: 24h. Gestern gegen 15Uhr habe ich den Fehler bemerkt. Heute gegen 15Uhr ward er behoben. Verdammte Scheiße

Gruß
Cpt.

Tataa!

Der erste Schritt zur Perfektion ist getan. Es lässt sich jetzt eine vollständige Messung durchführen - Generierung, Messung, Auswertung, Darstellung.

Ich habe mir mal ein Minimalskript geschrieben, was mir das ein wenig abnimmt:


#!/bin/sh

# wenn noch kein Sweep generiert wurde, dann bitte jetzt

if ! [ -r excitation.raw ]
then
# erstelle Sweep mit Default-Parametern
./generate
fi

# messen
./measure 

# Auswertung:
# Klirr (harm), Hann-Fensterung (hann), 
# 10ms Impulsantwort, 2ms Vorlaufzeit
# Terzglättung (3, 1/3 Oktave), K1, K2, K3, K5

./esweep harm hann 10 2 3 1 2 3 5

# Konvertierung in Gnuplot-Format

./raw2ascii esweep.raw


Weiter Kommentieren muss ich das nicht, oder?

Leider beendet sich Gnuplot sofort wenn ich es aus dem Skript mit Parametern aufrufe. Das ist natürlich bescheiden und deswegen muss die Darstellung noch händisch verrichtet werden.

Dazu habe ich eine Steuerungsdatei für Gnuplot geschrieben. Ebenfalls ganz simpel.



# logarithmische x-Achse
set logscale x 10

# wir wollen sichergehen, dass die y-Achse linear ist
unset logscale y

# ein bischen grid
set grid xtics mxtics ytics

# Achsen anpassen
set xrange [20:22500]
set yrange [-90:10]

# und nun plotten
plot "esweep.txt" using 1:2 with lines title "K1", "esweep.txt" using 1:4 with lines title "K2", "esweep.txt" using 1:6 with lines title "K3", "esweep.txt" using 1:8 with lines title "K5"


Das Ergebnis könnt ihr hier betrachten:



Das sind mal wieder meine hässlichen Popellautsprecher. Sind aber scheinbar gar nicht so schlecht, denn die Messung war ziemlich laut und der Klirr doch noch recht niedrig. Womit wir schon bei einer noch übrigen Baustelle sind. Absolutpegelmessungen sind leider noch nicht drin.

Gruß
Cpt.

Also, statt K5 hätte ich K4 geschrieben, kann aber auch so gewollt sein.

Sehr hübsch! Gratuliere!
Haste nun mit audiofisk hantiert, oder kannste nun alles selbst?

Wie lang dauert so ein Durchlauf?
Kann man noch mehr Harmonische darstellen?

K4 ist so gut wie nicht vorhanden. Das sieht man in der großen Impulsantwort. Um die anzuzeigen dauert es mit Gnuplot allerdings einen Moment, weil das ziemlich viele Samples werden können. Das werde ich noch beschränken, indem ich den Sweep zeitlich auf die wichtigen Teile reduziere (z. Z. ist er noch viel zu lang).

Der audiofisk kommt noch an die Reihe, ich war erstmal glücklich, dass ein ordentliches Ergebnis herauskommt.

Ein einzelner Durchlauf mit dem Skript dauert bei mir (P4 2,53GHz) etwa 15 Sekunden. Auch das lässt sich noch verringern, wenn ich den Sweep verkürze.

Theoretisch kann das Programm "esweep" beliebig viele Harmonische berechnen. Es gibt nur die Einschränkung, dass die Impulsantworten der Verzerrungen zeitlich immer näher zusammenrücken. Die höchste darstellbare Harmonische ist also diejenige, bei dem die Impulsantwort der nachfolgenden noch nicht hineinschmiert. Weiter kommt es auch darauf an, wie lang die ausgewählte Impulsantwort ist. Bei einer Länge von 512 Samples gibt es ein Spektrum mit 257 Stützstellen. Für K5 bedeutet das, dass es nur noch 50 Stützstellen gibt, K10 hätte nur noch 2 (es wird abgerundet). Irgendwann ist da also Schluss.

Allerdings ist bei Lautsprechern oberhalb von K5 auch nicht mehr viel los. Da verschwinden alle im Rauschen.

Gruß
Cpt.

Irgendwie habe ich was gegen Windows. Oder besser: gegen Microsoft.

Ich möchte Dokumentation über die Audioschnittstellen von Windows haben. Also gehe ich zuerst zur Seite des Herstellers dieses... Betriebssystems. Mal davon abgesehen, dass die jetzt total in Vista schwelgen, gibt es über die APIs quasi keine Dokumentation. Hey, die werden dafür bezahlt!

Nun gut, schauste Dir mal die ASIO API an. Wollte die von Steinberg runterladen, aber da kommt nur Datenmüll an. Ärgerlich, da man sich für jeden neuen Download registrieren muss. Super. Irgendwie kriege ich ne grade ne Scheiß Laune.

Gruß
Cpt.

Moin,

heute habe ich mal ein Skript entworfen, mit halbautomatische Directivity-Messungen möglich sind. Halbautomatisch, weil man den Lautsprecher noch von Hand ausrichten muss. Für vollautomatisches Messen bräuchte man einen motorbetriebenen Drehteller + ein entsprechendes Steuerprogramm. Das könnte an entscheidender Stelle im Skript eingefügt werden.

Das Skript ist nicht perfekt. Es fehlen ein paar Abfragen, wie z. B. ob alle Parameter übergeben wurden oder ob z. B. die Schrittweite gleich 0 ist, was für eine Division durch 0 sorgt (fällt mir grad ein, das kann man auch anders lösen). Es ging aber erstmal darum, zu zeigen, was mit ein wenig Programmieraufwand in einer Skriptsprache mit diesem Messprogramm möglich ist.

Hier erstmal das Skript:


#!/bin/sh
# Aufruf: sh direct.sh <start_winkel> <schrittweite> <stop_winkel>

# wenn noch kein Sweep generiert wurde, dann bitte jetzt

if ! [ -r direct_excit.raw ]
then
# erstelle Sweep mit 
# fstart=100Hz, fstop=20kHz, 1 Sekunde Dauer, Ausgabedatei
./generate -b 100 -e 20000 -t 1 -o direct_excit.raw
fi

# Anzahl der Messungen ist (stop-start)/schrittweite

N=`expr "$3" - "$1"`
N=`expr "$N" / "$2"`

i=0;

# hier kopieren wir die Vorlage mit den gnuplot-Kommandos

cp direct_template.plt direct.plt
echo '\n'"plot \\" >> direct.plt

# Schleife ausführen bis alle Winkel gemessen wurden

while [ $i -le $N ]
do
deg=`expr "$i" \* "$2"`
deg=`expr "$deg" + "$1"`

# hier könnte auch ein Programm zur automatischen Ausrichtung des LS
# stehen; wir machen es aber von Hand

echo -n "Lautsprecher auf" $deg "Grad ausrichten und Eingabetaste drücken"

# um den Benutzer aufzuwecken ein kleiner Beep
echo '\007'
read

echo  "messen..."

./measure -v 0.5 -i direct_excit.raw 

# Auswertung:
# Klirr (harm), Hann-Fensterung (hann), 
# 10ms Impulsantwort, 2ms Vorlaufzeit
# Terzglättung (3, 1/3 Oktave), nur K1

echo "auswerten..."

./esweep -o `echo "direct_"$deg".raw"` harm hann 10 2 3 1

# Konvertierung in Gnuplot-Format

echo "konvertieren..."

./raw2ascii `echo "direct_"$deg".raw"`

# wir brauchen die raw-Datei nicht mehr, also weg damit

rm -rf `echo "direct_"$deg".raw"`

# und nun hängen wir den benötigten plot-command an direct.plt an

echo -n  "\"`echo "direct_"$deg".txt"`\" using 1:2 with lines title\"" $deg "Grad\"" >> direct.plt
if [ $i -lt $N ]
then
echo ", \\" >> direct.plt
fi

# i um 1 erhöhen
i=$(expr $i + 1)
done

# gnuplot aufrufen
# gnuplot: logarithmischer plot

/usr/local/bin/gnuplot direct.plt

# xzgv stellt Bild dar
# das "&" sorgt dafür, dass das Skript verlassen wird und nur "xzgv" offen bleibt

/usr/local/bin/xzgv direct.png&



Da es kommentiert ist, sage ich nicht viel mehr dazu.

Die Vorlage für die gnuplot-Kommandodatei sieht so aus:


# direct_template.plt

# logarithmische x-Achse
set logscale x 10

# wir wollen sichergehen, dass die y-Achse linear ist
unset logscale y

# ein bischen grid
set grid xtics mxtics ytics

# Achsen anpassen
set xrange [20:22500]
set yrange [-90:10]

# output nach png
set output "direct.png"
set terminal png picsize 800 600

# und nun plotten
# durch das Skript wird ein plot-Befehl erzeugt und hier angehängt


Und zum Schluss noch eine quick'n'dirty Messung meiner Tröten unter 0, 15 und 30 Grad. "Quick" weils schnell ging (weniger als eine Minute), "dirty" weils mir scheißegal war, ob das wirklich 15 oder 30 Grad waren. Es kommt aber ungefähr hin.



Ist doch ganz nett, oder?

Gruß
Cpt.

So, nun hab ich etwas, was wohl so noch nicht sehr häufig zu sehen war: Klirrverläufe unter Winkeln.



Dazu musste ich obiges Skript nur ganz wenig abändern.

Die absoluten Pegelunterschiede kommen durch die miserablen Messbedingungen zustande. Wenn man keinen Drehteller hat kriegt man sowas nicht gut hin. Da muss wohl mal die Kreissäge angeworfen werden.

Man sieht aber sehr schön, wie die K3-Spitze bei 1,5kHz mit zunehmenden Winkel schwächer wird. Das ist ein ganz simpler Vorgang. K3 bei 1,5kHz bedeutet zusätzlicher Schall bei 4,5kHz. Da haben wir schon erheblich mit der Bündelung durch die Membran und das Gehäuse zu kämpfen (der K3 ist dem TMT zu verdanken).

Ich warte auf Bekundungen des Erstaunens.

Gruß
Cpt.

P.S.: ich vergaß zu erwähnen: der hohe Klirr bei niedrigen Frequenzen liegt an der geringen SNR, weil der Sweep erst bei 100Hz seinen vollen Pegel erreicht. Dann fehlt untenrum einfach ein wenig Energie. Außerdem ist er mit 1s im Bereich zwischen 100Hz und 20kHz kürzer als der, den ich für das Bild einige Posts vorher benutzt habe. Das kratzt auch an der SNR. Und die Messung war etwas lauter.

Geht das nur mir so oder können auch andere das letzte Bild nicht laden?

Gruß
Cpt.

Das Bild unter "Klirrverläufe unter Winkeln." geht bei mir auch nicht.

Gut, dann lade ich das nochmal hoch. Irgendwann. Heute Abend...

Gruß
Cpt.

Bild ist jetzt drin.

Gruß
Cpt.

Hallo,

Cpt._Baseballbatboy schrieb:

Wenn man keinen Drehteller hat kriegt man sowas nicht gut hin. Da muss wohl mal die Kreissäge angeworfen werden.

unglaublich, so schnell mißt Dein Programm?
Drehteller gibt es bei C
für gut 5 oder 10 Eier.

Sehr geehrte Damen und Herren,

ich präsentiere: den Wasserfall.



Ist doch leichter als Pfannkuchen essen.

Gruß
Cpt.

P.S.: bevor dumme Fragen kommen, eine auf Perioden normierte Darstellung ist vorgesehen und war schon implementiert, ist aber leider noch fehlerhaft.

Der Wasserfall ist ein nettes Spielzeug. Vor allem kann man ihn so wunderbar fälschen.

Da haben wir zuerst mal eine Messung mit nahezu keiner Glättung (1/8-Oktave):



Dann die Terzglättung (1/3-Oktave):



Und zum Schluss die Oktavglättung:



Der perfekte Lautsprecher

Aber das ist ja eigentlich Standard. Nicht ganz der Standard ist der Blick auf das Ausschwingen der Klirrkomponenten, z. B. K3 (1/8-Oktave geglättet):



Ein furchtbarer Anblick. Jetzt suche ich noch eine Möglichkeit, das vielleicht in ein Diagramm zu pressen.

Gruß
Cpt.

Ich bin mal ganz vorsichtig und sage, dass es nun auch unter Linux läuft. Zumindest die Generierung und Auswertung funktionieren einwandfrei, bei der Messung selber bin ich mir noch nicht sicher, ob es ein Problem mit dem Linux-eigenen Soundkartenmixer oder mit meinem Programm gibt. Zumindest habe ich schonmal den Frequenzgang meiner Soundkarte messen können.

Gruß
Cpt.

Ich habe eine gesunde Abneigung gegen Linux. Genauso wie gegen Windows.

Warum sind die nicht in der Lage, eine ordentliche Dokumentation zu ihren Schnittstellen zu veröffentlichen? Eine Minimalbeschreibung der API plus Beispiele sind eben keine Dokumentation.

Die Soundausgabe von OpenBSD habe ich innerhalb eines Tages hinbekommen. Warum? Weil "man audio" (für alle Nicht-UNIXler: das ist der Aufruf einer sogenannten man-page, der zentralen Anlaufstelle für Fragen in UNIX-Systemen) eine wunderbare Dokumentation der Audio-API ist. Durchgelesen, verstanden, programmiert, funktioniert.

Ich weiß ja, dass Dokumentation anstrengend ist, und man sich lieber darauf konzentriert, das Programm/die Bibliothek zu verbessern. Aber das gehört zu einer guten Softwareentwicklung dazu (hab ich eigentlich schon die Doku für dieses Programm geschrieben? *duckundweg*)

Also: das Abspielen des Sweeps funktioniert unter Linux. Aber das Aufnehmen nicht. Und ich kann den Fehler nicht finden, u. a. weil mir eine vernünftige Doku fehlt.

Blöder Mist.

Gruß
Cpt.

$ man audio
Kein Manual-Eintrag für audio vorhanden

Stimmt.

Ich bin kein Programmierer aber seit inzwischen 10 Jahren Linux Anwender. Inzwischen ist eigentlich ALSA die Standard Audio Schnittstelle unter Linux. Auf der Projekt Homepage ist die Schnittstelle dokumentiert. Vielleicht hilft dir das weiter.

Röhrender_Hirsch schrieb:

$ man audio Kein Manual-Eintrag für audio vorhanden Stimmt.

Gibts ja auch nur unter Open- und NetBSD. Man kann die z. B: hier finden: http://www.openbsd.o...rch=i386&format=html

ALSA habe ich mir schon angeschaut. Lauter Tutorials. Tutorials sind _keine_ Dokumentation. Sie können als Ergänzung hinzugefügt werden, aber am wichtigsten ist eine gute Beschreibung der Schnittstelle.

Genauso wie bei JACK. Habe ich mir gerade angeschaut. Keine vernünftige Dokumentation, nur irgendwelche HowTo's.

Das einzige, was Linux dem MSschen Windows voraus hat, ist, dass man nicht lange nach den HowTo's suchen muss.

Gruß
Cpt.

Mit der fehlenden Dokumentation du nicht unrecht. Was habe ich mich totgesucht als Alsa auf einem System mal nicht funktioniert hat.

Zu der API-Geschichte. Hast du diese Seite gefunden? http://www.alsa-project.org/alsa-doc/alsa-lib/index.html Unter "API links" und dann "Data Structures" steht einiges an Information.

Ein Bild.

Ein ganz besonderes Bild.

Weil es unter Windows entstanden ist.

Was soviel bedeutet wie: das Messprogramm läuft jetzt auch unter Windows. Unter Linux übrigens auch.

Geschafft habe ich das mit Hilfe von portaudio, eine plattformübergreifenden Audio-I/O-API, die ich schonmal verwendet habe, aber unter OpenBSD nicht weiter benutzt weil die dort nicht funktioniert.

Morgen (bzw. heute) werde ich das mal zusammentüten und ein paar ausführbare Windowsdateien bereitstellen.

Gruß
Cpt.

Hallo Cpt.,

Morgen (bzw. heute) werde ich das mal zusammentüten und ein paar ausführbare Windowsdateien bereitstellen.

Schön, dann werde ich das Programm gleich mal ausprobieren.

Gruß - Richard

Schön, vielleicht finden sich noch andere zum Testen. Zur Vorbereitung empfehle ich allen Interessierten, sich Gnuplot zu installieren, sonst gibts keine Bildchen.

Ich muss aber nochmal genauer untersuchen, warum die Klirrkurven so wie auf dem Bild aussehen (besonders der Anstieg zu hohen Frequenzen macht mir Sorgen). Eventuell ist diese Messung da in die Hose gegangen (das kann bei Soundkarten passieren, aus verschiedenen Gründen). Da steht noch ein wenig testen aus.

Gruß
Cpt.

Das Programm kann vorerst hier heruntergeladen werden (93kB). Der Server ist ein bisschen langsam, max. 120kBit/s, also Geduld.

Einfach in ein beliebiges Verzeichnis entpacken.

Im Unterverzeichnis "scripts" befindet sich eine Batch-Datei "esweep.bat". Wenn man die ausführt, wird erst eine Datei mit dem Sweep erzeugt, dann die Messung durchgeführt, dann ausgewertet (10ms lange Impulsantwort, Vorlaufzeit 2ms, 1/3-Oktavglättung, K1, K2, K3, K5), in ein für gnuplot verständliches Format konvertiert und dann gnuplot mit der Datei "esweep.plt" aufgerufen. Als Ergebnis sollte sich dem Verzeichnis dann ein png-Bild "esweep.png" befinden.

Vorrausgesetzt, gnuplot ist richtig installiert. Eigentlich ist das ganz einfach: den Windows-Installer von gnuplot herunterladen, das Programm installieren, und dann in den Umgebungsvariablen (zu erreichen über die Eigenschaften des Arbeitsplatzes und dann "Erweitert") die Variable "GNUPLOT" mit dem Wert des Pfades zu der "wgnuplot.exe" (also dem Installationspfad, z. B: "D:\Programme\gnuplot\wgnuplot.exe").

Probiert es aus, Fragen bitte hier.

Gruß
Cpt.

Hallo

Verfolge den Fred schon ein wenig und wollte mir die Windowsdatei mal runterladen zum ausprobieren, aber irgendwie hat mein Rechner gerade eine halbe Stunde versucht deinen Server zu erreichen, leider erfolglos.
Kannst Du das vielleicht noch irgendwoanders hochladen?

Gruß
Martin

Wollte ich auch, und zwar auf den Server der Projektseite (siehe Signatur). Aber ich bin wohl zu doof dazu.

Ich such mal was anderes.

\Edit

eigentlich sollte es jetzt besser gehen. Wenn nicht, ich hoffe das ich gleich ne funktionierende Stelle bekomme.

Gruß
Cpt.

So wie ich das sehe haben nun doch ein paar wenige das Programm laden können (die Log-Datei sagt drei Downloads).

Ich geb mal noch ne ganz flotte Gebrauchsanweisung:

Anmerkung: bitte bei allen Parametern auf die angelsächsische Schreibweise von Zahlen achten. "1.1" statt "1,1"

Sweep-Generierung

generate -t <dauer> -r <samplerate> -b <fstart> -e <fstop> -s <spektrum> -o <ausgabedatei> Alle Parameter sind optional. Die Default-Werte sind sorgfältig gewählt, und eigentlich liegt kein besonderer Grund vor, diese zu ändern. -t: Dauer des Sweeps. Standard 2s, Minimum 1s. Wer einen schnellen Rechner mit viel Speicher hat, der kann auch mal mehr ausprobieren. -r: Samplerate: Standard sind 44,1kHz, Minimum 8kHz, nach oben offen. Der beste Wert ist die interne Samplerate der Soundkarte (meist 44,1kHz oder 48kHz) oder ein Teiler davon -b, -e: Start- und Stopfrequenz: Standard 20Hz-20kHz, Minimum 10Hz, Maximum <Samplerate/2. Der Sweep beginnt und endet _nicht_ bei diesen Frequenzen. Sie kennzeichnen den Bereich, in dem die gleiche Energie pro relativer Bandbreite abgegeben wird. Darunter und darüber nimmt die Energie langsam zu bzw. ab. Für Hochtöner sollte die Startfrequenz oberhalb 200Hz liegen. -s: Spektrum des Sweeps. Standard ist 0, mögliche Werte sind 0..2. 0 entspricht einem rosa Spektrum und ist im Normalfall die beste Wahl. 1 ist ein weißes Spektrum, 2 ein rotes, beide sind für Spezialfälle gedacht, die hier nicht näher erläutert werden sollen. Ist aber ganz nett, das mal auszuprobieren. -o: Ausgabedatei. Standard ist "excitation.raw". Beispiel: generate -t 3.2 -b 300.5 -e 10000 -r 44100 -s 1 -o sweep.raw

Messen

measure -i <Datei mit Sweep> -o <Ausgabedatei> -v <Lautstärke> Alle Parameter sind optional. -i: Datei die den Sweep enthält. Standard: "excitation.raw" -o: Ausgabedatei. Standard: "ir.raw" -v: Lautstärke. Standard 0.2, Bereich 0.0...1.0. Der Maximalwert übersteuert mit Sicherheit die Soundkarte, ein praktischer Höchstwert ist 0.7. Beispiel: measure -i sweep.raw -o response.raw -v 0.5

Auswertung

esweep -i <Eingabedatei> -o <Ausgabedatei> <Modul> <Moduloptionen> -i: Eingabedatei. Standard "ir.raw" -o: Ausgabedatei. Standard "esweep.raw" Module: harm csd phase Modul harm: Berechnet die Harmonischen. Aufruf: esweep harm <Fenster> <IR Länge> <Vorlaufzeit> <Glättungsfaktor> <Harmonische...> Fenster: Fensterfunktion mit der die Impulsantwort bewertet wird. Mögliche Fenster sind: Rechteck: "rect" von Hann: "hann" Hamming: "hamm" Bartlett: "bart" Blackman: "black" Zur Theorie der Fenster bitte in die Standardliteratur schauen. IR Länge: Länge der Impulsantwort in Millisekunden. Vorlaufzeit: die Impulsantwort wird automatisch anhand des Maximums in der Eingabedatei gesucht. Die Impulsantwort kann aber schon vor diesem Maximum wichtige Werte enthalten. Die Vorlaufzeit kennzeichnet die Zeit in Millisekunden, die vor dem Maximum schon für die Impulsantwort verwendet wird. Die Länge der Impulsantwort ändert sich dadurch _nicht_. Glättungsfaktor: Minimum 1. Ist der Kehrwert der Glättung. "3" entspricht der Terzglättung: 1/3-Oktave Harmonische: durch Leerzeichen getrennte Liste der zu berechnenden Harmonischen, beliebige Reihenfolge, die Grundwelle wird _immer_ berechnet. Beispiel: esweep harm hann 10 2 3 1 2 3 5 Modul csd Berechnet das Wasserfallspektrum für _eine_ Harmonische Aufruf: esweep csd <Fenster> <IR Länge> <Vorlaufzeit> <Glättungsfaktor> <Schrittweite> <Schritte> <Harmonische> Fenster, IR Länge, Vorlaufzeit, Glätungsfaktor: siehe Modul "harm" Schrittweite: Zeit in Millisekunden, die auf der Impulsantwort fortgeschritten wird. Bestimmt die zeitliche Auflösung im Wasserfall. Das Minimum ist der Kehrwert aus der Samplerate. Schritte: Anzahl der Schritte. Schritte * Schrittweite ergibt den Zeitbereich, für den das Wasserfallspektrum berechnet wird. Harmonische: _Eine_ Harmonische, für die der Wasserfall berechnet wird. Siehe auch: Modul "harm" Beispiel: esweep csd black 10 2 3 0.1 30 1 Modul phase Wird in Zukunft Berechnungen mit der Phase ermöglichen. Zur Zeit kann nur der allpasshaltige Phasengang errechnet werden, die beliebte Darstellung der Minimalphase ist noch nicht implementiert. Aufruf: esweep phase Keine weiteren Optionen. Die Eingabedatei muss durch das Modul "harm" erzeugt worden sein. Bitte beachten, dass das Ergebnis nur eine Annäherung ist.

Konvertierung ins Gnuplot-Format

raw2ascii <Eingabedatei> Konvertiert die binäre Eingabedatei in ein für Gnuplot verständliches Format. Bei Frequenzgängen wird der DC-Anteil verworfen, um logarithmische Darstellungen in Gnuplot zu ermöglichen. Die Ausgabedatei hat den gleichen Namen wie die Eingabedatei, aber die Endung "txt". Die Eingabedatei "beispiel.txt" wird demnach überschrieben.

Darstellungen in Gnuplot

Im Folgenden gehe ich davon aus, dass sich die Daten in der Datei "esweep.txt" befinden.

Die folgenden Beispiele gehen nur auf den plot/splot-Befehl von Gnuplot ein. Die verschiedenen settings zum Aufhübschen der Grafik lasse ich mal außen vor, die sprechen sich schon rum. Im Allgemeinen ist es sinnvoll, sich fertige Kommandodateien zu basteln, wie z. B. die "esweep.plt" im Verzeichnis "scripts". Das spart Tipparbeit.

Man kann sich auch den erzeugten Sweep und die von "measure" errechnete Impulsantwort in Gnuplot anzeigen lassen, aber ich würd das lassen. Erstens erkennt man da nicht viel und zweitens ist Gnuplot viel zu langsam dafür.

1. Beispiel:
Mit dem esweep-Modul "harm" wurden K1, K2, K3 und K5 berechnet. In der Datei "esweep.txt" (durch raw2ascii erzeugt) befindet sich der Amplitudenfrequenzgang in den geraden Spalten (2, 4, 6, ...), der Phasenfrequenzgang in den darauffolgenden ungeraden Spalten (3, 5, 7, ...). In der ersten Spalte ist die jeweilige Frequenz zu finden.

Der plot-Befehl für die Amplitudenfrequenzgänge lautet daher:

plot "esweep.txt" using 1:2 with lines title "K1", \ "" using 1:4 with lines title "K2", \ "" using 1:6 with lines title "K3", \ "" using 1:8 with lines title "K4"

Der "\" kennzeichnet den Zeilenumbruch. Um die Phase darzustellen ersetzt man in "using" einfach die zweite Ziffer durch die darauffolgende ungerade Zahl, also z. B.

plot "esweep.txt" using 1:3 with lines title "K1"

Ein Wasserfall kann mit dem splot-Befehl dargestellt werden:

splot "esweep.txt" using 1:2:3 with lines title "CSD"

Hier sind keine Phaseninformationen vorhanden. Man kann auch mehrere Wasserfälle in ein Diagramm packen, vorausgesetzt, es existieren zwei Dateien, z. B. "esweep_K1.txt" und "esweep_K2.txt":

splot "esweep_K1.txt" using 1:2:3 with lines title "CSD K1", \ "esweep_K2.txt" using 1:2:3 with lines title "CSD K2"

Bitte beachten, dass das esweep-Modul CSD die jeweilige Harmonische auf ihr Maximum normiert. Im Wasserfall des letzten Befehls werden also K1 und K2 scheinbar den gleichen Pegel besitzen. In einer zukünftigen Version wird ein Option angeboten werden, die eine andere Normierung erlaubt.

Das wars erstmal. Fragen?

Gruß
Cpt.

Eh ichs vergess: das Programm kann jetzt bei tiki heruntergeladen werden: http://www.hifi-foru...peaker/messprogramm/

Gruß
Cpt.

Das schöne an quasi-reflektionsfreien Messungen ist ja, dass man den Raum mehr oder weniger ausblenden kann. Unschön ist daran, dass dadurch auch der verwertbare Frequenzbereich und besonders die Frequenzauflösung sinkt.

Das ist nicht weiter schlimm, wenn die erste Raumreflektion sehr spät ist. Ist sie es nicht, bekommt man Probleme. Wie z. B. hier:



Man, was hab ich mir den Kopf zerbrochen, wo diese frühe Reflektion nach gerade einmal 1ms herkam. Alle mögliche mit dem Zollstock abgegangen: Kantenreflektion, am Lautsprecherständer, an der Wand dahinter? Zusätzlich einige Kissen an verdächtige Stellen gestopft.

Irgendwann fällt mein Blick auf das zum Mikrofonständer umfunktionierte Kamerastativ. Klar, zwischen Spitze vom ECM8000 und Stativ sind es knapp 15cm, das kommt hin. Also mal kurz den Ständer gegen meinen langen Arm eingetauscht, und schon war die Reflektion weg.

Offensichtlich muss ich wohl doch noch los, mir nen richtigen Mik-Ständer organisieren. Hat zufällig wer einen günstig abzugeben?

Achja, bevor es Fragen von der Windows-Fraktion gibt: nein, ihr könnt die Impulsantwort noch nicht so schön exportieren. Das geht bisher nur unter richtigen Betriebssystemen

Vielleicht bau ich heut Abend noch ne neue Version. Ist ja nicht unwichtig, die Möglichkeit.

Gruß
Cpt.

Die neue Version steht jetzt bereit. Ich habe eine Nummerierung eingeführt. Die alte Version hat die Nummer 0.1, die neue 0.1.1. Das Ziel für 0.2 lautet: Kalibrierung und damit Absolutpegelmessung.

In 0.1.1 ist folgendes hinzugekommen:

wie schon angedeutet kann jetzt die Impulsantwort extrahiert werden. Der Aufruf lautet:

esweep ir <Länge> <Vorlaufzeit> <Harmonische>

Also wie schon im Modul "harm", siehe Anleitung oben. Natürlich kann das Ergebnis auch wieder mit "raw2ascii" in ein Gnuplot-Format konvertiert werden.

Weils so einfach war kann das gleiche Modul auch noch die Sprungantwort ausgeben. Dazu bedarf es nur eines kleinen weiteren Kommandos:

esweep ir step <Länge> <Vorlaufzeit> <Harmonische>

Eine weitere nette Sache ist, dass jetzt die der Frequenzgang der Messkette - ohne Mikrofon! - kompensiert werden kann. Bisher profitiert davon aber nur das Modul "harm". Dazu folgende Vorgehensweise:

1.) Soundkarten Ein- und Ausgang miteinander verbinden. Ich gehe einfach mal davon aus, dass es sich dabei um das schwächste Glied der Kette handelt, zwischengeschaltete Verstärker sollten sehr viel bessere Frequenzgänge besitzen.

2.) mit "measure" eine Loopback-Messung durchführen

3.) der Datei einen sinnvollen Namen geben

4.) im Folgenden die Auswertung mit dem Parameter "-c" aufrufen:

esweep -c <Dateiname> harm <Fenster> ...

Dateiname ist natürlich der in Punkt 3.) vergebene.

Hinter dieser Adresse sind sowohl die alte als auch die neue zu finden:

http://141.30.146.61/skvf/speaker/messprogramm/

Als Beispiel mal die Sprungantworten der Grundwelle und K3. Wie Ihr in den bisher von mir durchgeführten Messungen gesehen habt, versteckt sich in meinem Lautsprecher eine gepflegte Membranresonanz, die weder im Frequenzgang noch im Wasserfall von K1 erkennbar ist (höchstens Ansatzweise, wenn man weiß, dass die da ist).

Der Klirrverlauf und der Wasserfall von K3 zeigen ein ganz anderes Bild. Genauso wie die Spungantworten, beliebt bei jung und alt und ungefähr so aussagekräftig wie ein Glas Wasser.

Hier das von K1:



Nichts zu sehen, außer ein paar verstreuten Zacken auf der Krone.

Viel interessanter dagegen die Sprungantwort von K3:



Die ist schon viel eher auf Zack. Und diese kleinen Spitzen, die beschreiben eine Welle mit der Periodendauer 0,2ms. Nimmt man davon den Kehrwert, sind wir wieder bei 5kHz. Und das korreliert doch prächtig mit der im Wasserfall gesehenen Resonanz.

Ganz ehrlich, ich bin immer wieder fasziniert, welche Einsichten in den Lautsprecher diese Messmethode ermöglicht. Alterwürdige MLS-Messungen können dagegen nur abstinken

Gruß
Cpt.

Ich habe es jetzt hinbekommen, bei Berlios Dateien hochzuladen:

Die Windows-Version gibt es hier: http://prdownload.berlios.de/esweep/esweep0.1.1.zip

Den dazu passenden Quellcode: http://prdownload.berlios.de/esweep/esweep0.1.1.tar.gz

Wer immer den aktuellsten Code haben will, der muss ihn sich per CVS organisieren.

\Edit: und noch ne Info an diejenigen, die sich immer noch die allerste von mir gepostete Windows-Version herunterladen möchten: die ist veraltet, und lest bitte den Thread zu Ende. Ich würde gern den Link auf meinen Router herauseditieren, aber die Forensoftware verweigert mir das in ihrer faschistischen Art.

Wer die Software dennoch direkt ab Werk möchte, hier der Link in das entsprechende Verzeichnis:

ftp://fabricius.homeip.net/pub/esweep

Die etwas weiter oben in diesem Thread geposteten Links sind allerdings schneller, zuverlässiger, und meistens auch aktueller.

Gruß
Cpt.