Neue Boxsim-Version 1.10

[poor but loud]

Endlich mal wieder ein Programm, dass meine CPU auslastet.

Ich bin froh über jede Anwendung, die den PC nicht so stark auslastet.

[VENTILIERT]

Mir ist es lieber, wenn (fast) alle Resourcen gebunden werden, wenn die Berechnung dann schneller fertig ist. Die 4 Kerne sind bei einer Optimierung ungleichmäßig zwischen 30 - 70 % ausgelastet. Bei einer zweiten O. gleichzeitig alle zu knapp 100%. Eine Arbeiten mit Windows ist aber noch möglich.

Die befasse mich oft mit Videobearbeitung (Urlaubsvideos) usw..
Seit dem mehr Kerne unterstützt werden, ist man wessentlich schneller fertig. Ich denke, dass ist ein Vorteil (für mich).

EDIT:
Die Testoptimierung (Vergleichszwecke) vom default Projekt (Bass u. Höhen mittel, Impedanz > 2 Ohm, Wirkungsgrad egal) dauert zwischen 7 u. 8 Minuten.
Ich bin sehr zufrieden.

[Grashopper]

Also bei Boxsim bekomme ich gerade mal 25% Auslastung hin, also nur 1 Kern. Da liegt bei meinem 940BE zu viel Potential brach. Schade das Boxsim keine Mehrkernunterstützung hat, würde die Berechnungen deutlich verkürzen auch wenn es jetzt schon nicht sonderlich lange dauert.
€: Habe gerade gesehen das es doch eine Dualcore-Unterstützung gibt wenn man die Weiche optimieren lässt. Leider klappt das nicht bei den "einfachen" Berechnungen.

@UweG: Ist eigentlich eine Art "Berechnungsbalken" geplant ? Wenn Boxsim den FG berechnet wird es ja nur recht unscheinbar unten links angezeigt. Vielleicht könnte man dort einen Progressbalken platzieren um die Berechnung optisch hervorzuheben. Manchmal bin ich schon 2 Schritte voraus und übersehe dabei das noch gerechnet wird.

[VENTILIERT]

Bei meiner Vista 64 Version stelle ich eine (anteilige) Auslastung auf allen Kernen fest

[Grashopper]

Ja, das macht der Task-Scheduler von Windows. Der teilt die Berechnungen auf 4 Kerne auf, jedoch nicht parallel sondern seriell. 25% Auslastung bedeutet somit nur 1 Kern. Legst du die Zugehörigkeit von Boxsim auf einen Kern hast du dort 100% Auslastung und die restlichen Kerne werden nicht genutzt.
Wirklich nötig wäre ein Mehrkernunterstützung für mich jedoch nicht. Mit 3.4GHz dauert es nun wirklich nicht lange bis die Berechnung fertig ist. Ein Viertel (ca.) der Rechenzeit, die man durch eine Multicore-Unterstützung erhalten würde, wäre jedoch grandios

[VENTILIERT]

Ich meine, wenn ich mir jeden Kern ansehe, dann ist das ersichtlich. Auch beim Gadget CPU Usage ist dies erkennbar......

[VENTILIERT]

Außerdem stelle ich leichte Darstellungsfehler des Weichenoptimierers bei 1920x1200 fest, falls noch nicht bekannt. Im unteren Bereich des Fensters wären 20 - 50 Pixel mehr Höhe nicht schlecht.
@grashopper: Welches OS verwendest Du? Wieviel RAM hast du verbaut?
Ein Viertel der Rechenzeit wird wahrscheinlich auch nicht möglich sein. Durchschnittlich sind die Kerne bei mir 50 % ausgelastet. Die einzelnen Kerne zwischen 30 u. 90 Prozent, wie gesagt. Ich wundere mich mich nur, warum wir solche Abweichungen haben.
OS Vista 64 SP2
8GByte
4 x 3,2 GHz
??

[Grashopper]

WinXP 32bit mit 4GB Ram
Phenom II 940 @3.4GHz

Wir haben aber keine Abweichungen. Boxsim scheint den normalen FG auf einem Kern zu berechnen (~25% Gesamtast) und bietet erst beim Bauteiloptimierer eine Dualcoreunterstützung (~50% Gesamtlast).
Oder hast du beim reinen FG berechnen eine Auslastung von über 25% ?

[VENTILIERT]

Ich sags Dir, wenn der Optimierer fertig ist (läuft gerade)...
Außerdem ist es nicht immer von VOrteil, wenn man selbst die Werte für die Weichenänderung überprüft. Ich werde nächstes Mal E12 Reihe einstellen.

[UweG]

Boxsim scheint den normalen FG auf einem Kern zu berechnen (~25% Gesamtast) und bietet erst beim Bauteiloptimierer eine Dualcoreunterstützung (~50% Gesamtlast).

Ganz genau. Die normale Berechnung läuft nur in einem Thread, der Optimierer in dreien, wobei einer der drei nur sehr wenig zu tun hat.
Ich habe auch schonmal mit einer 5-Thread-Version des Optimierers experimentiert, die hat sich aber auf einem Dualcore so schlecht bewährt, dass ich annehme, dass sie selbst auf einem Quadcore nur marginal schneller wäre als die jetzige.

Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

[istec1003]

[...]
Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

Sehe ich genauso. Normale Berechnung ist ausreichend schnell, Optimierer würde profitieren.

[Grashopper]

Mal so als allgemeine Frage:
Wie schnell empfindet ihr Boxsim subjektiv bei normaler Rechnung / beim Optimierer?
Mein persönlicher Eindruck ist:
Normale Berechnung könnte einen Deut schneller sein, es stört aber nur wenig.
Der Optimierer ist zwar noch benutzbar, würde aber von einer Beschleunigung deutlich profitieren.

Ich würde es begrüßen wenn die normale Berechnung schneller ablaufen würde. Vielleicht kann man das auch in 3 (2) Threads erledigen. Immerhin wird die normale Berechnung öfter ausgeführt. Subjektiv stört mich das etwas. Mit dem Weichenoptimierer kann ich leben.

[Peter K]

Hallo All und Uwe im Speziellen,

nachdem wir uns in einer regionalen Selbstbaugruppe etwas ausführlicher mit einem selbstgemessenen Probeprojekt (360 Grad gemessen in 30 Grad Schritten sowohl horizontal als auch vertikal) befasst haben und eine Weichenentwicklung sowohl in Audiocad als auch in Boxsim gemacht haben, sind wir übereinstimmend zu folgender Einschätzung gelangt:

Zitat aus einem anderen Forum:

"Wenn Uwe das Programm schon so "deppensicher" angelegt hat, da wäre es sinnvoll, bei der Abfrage mit den eigenen Messungen die Schallwandmaße, Treiberposition, Treibergrößen etc. des Messobjekts abzufragen und genauso wie bei den Visatonchassis auf unendliche Schallwand rückzurechnen und dann bei Gehäuseänderungen umzurechnen.
So, wie es derzeit angelegt ist, sind SÄMTLICHE Berechnungen des Progs ausser dem Achsenfrequenzgang im Original(Mess-)gehäuse und dem Impedanzverlauf, möglicherweise noch der Phase für die Tonne...., sobald man andere Schallwandabmessungen eingibt, als bei der Messung verwendet.
Wahrscheinlich sind auch die Winkelsimulationen im Messgehäuse nicht brauchbar, da vermutlich bestimmte Welligkeiten im Achsenfrequenzgang, die von Kantenreflexionen herrühren, falsch interpretiert werden, da keine Rückrechnung auf unendliche Schallwand stattfindet.
Da dann aber auch weder der Energiefrequenzgang noch das Bündelungsmaß richtig berechnet wird (mach boxsim sowieso falsch), wäre es sinnvoller, bei Verarbeitung von eigenen Messungen alle anderen Berechnungen ausser dem Achsenfrequenzgang abzuschalten....
Wenn du dir mal den HT unter Chassis ansiehst, dann wird das deutlich: Da wird der wellige Frequenzgang der Achsenmessung als Halbraumfrequenzgang "verkauft"."

Dann haben wir mal probeweise andere Schallwandabmessungen im gemeinsamen Aussengehäuse und deutlich andere Treiberanordnungen der gemessenen Treiber eingegeben und sind dann zu folgender Einschätzung gelangt:

Zweites Zitat:

"Ja, war auch zu erwarten, da Summierung im unendlichen stattfindet.
Mit anderen Worten als Nachtrag zu meinem vorherigen Post:
Es ist wohl vollkommen egal, welche Schallwandabmessungen und Treiberpositionen man bei eigenen Messungen verwendet:
Die Achsensimu ist jeweils gleich korrekt, den Rest der Berechnungen incl. Energiefrequenzgang etc. kann man vergessen..."

Drittes Zitat:

"Auch das ist ausgezeichnet zusammengefasst und muss bei Simulationen mit
eigenen Messungen berücksichtigt werden:
Nur der Hauptfrequenzgang (Frequenzgang Gesamtbox) des selbst gemessenen
Lautsprechers ist korrekt und zwar für den Mikrofonmesspunkt.

Ein Schritt weiter:
Würde man ins Boxsim für den Hochtöner und den Tieftöner die 30-Grad Messung einpflegen,
dann würde Boxsim auch diesen Frequenzgang unter Frequenzgang Gesamtbox korrekt darstellen,
denn Boxsim verknüpft die eingelesenen Chassis-Frequenzgänge korrekt.

Für die anderen Winkelmessungen müsste man genauso verfahren.

Für eigene Messungen gilt
(Mikrofon ist während der Messung an einer festen Position):
Man müsste also für jeden Winkel ein Boxsim-Projekt anlegen, wenn man in Boxsim die
korrekten Frequenzgänge unter Winkeln haben möchte."

Nach unseren Erfahrungen muß man also bei Verarbeitung von eigenen Messungen folgendermaßen zusammenfassen:

1.) Der Frequenzgang auf Achse wird korrekt simuliert, dabei ist es unerheblich, welche auch vom Messobjekt abweichende Schallwandgröße und Treiberposition gewählt wird.

2.) Auch mit der korrekten Schallwandabmessung des Messobjekts werden Ausser-Winkel Frequenzgänge und somit auch Energiefrequenzgang und Bündelungsverhalten falsch berechnet.

3.) Daraus folgt, daß man dann nicht auf einen Ausser-Achse-Winkel (wie z.B.) 30 Grad optimieren kann, da der Winkel wie auch alle anderen nicht korrekt simuliert wird.

4.) Die Verwendung des Optimierers in der vorliegenden Form macht bei Projekten mit eigenen Messungen keinen Sinn, da all die umfangreichen Berechnungen eh nicht benötigt werden, falsch sind und völlig unnötige Rechenzeit kosten.

5.) Will man auch auch Winkelmessungen von eigenen Projekten richtig simulieren, dann muß man für jeden Winkel ein eigenes Projekt anlegen und dann die Frequenzweichenbauteile per Hand in jedes einzelne Winkelprojekt übertragen.
Das geht aber selbst mit dem Methusalem Audiocad deutlich schneller und komfortabler.

Für mich folgt daraus, daß die Arbeitsweise des boxsim-Optimierers grundlegend verändert werden sollte. Wie, ist ja im Wesentlichen in entsprechenden Threads auch hier gesagt worden.
Als wichtigstes sollte der reine Optimierungslauf NUR mit dem Achsenfrequenzgang stattfinden und nur nach Abschluß der Optimierung der ganze Wust an anderen Berechnungen EINMALIG gemacht werden, allerdings nicht bei Projekten mit eigenen Messungen, da dann all die anderen Auswertungen eh überflüssig wie ein Kropf sind.
Das würde auch die bisher ätzend lange Laufzeit der Optimierung deutlich beschleunigen.

Viele Grüße
Peter Krips

[UweG]

Hallo Peter,

vielen Dank für Deinen ausführlichen Beitrag, aber die Aussagen sind z. T. sehr irreführend, weil unter z. T. nur bei genauem Lesen nachvollziehbaren Voraussetzungen verständlich. Eine ausführliche Antwort kommt noch.

Eines vorab: Gemessene Frequenzgänge für Boxsim sind immer auf Achse zu messen und zwar in einer der vier fest definierten Umgebungen. Alles andere ist falsche Bedienung und kein Programmfehler, allenfalls ein Dokumentationsmanko.

[UweG]

So. Jetzt habe ich etwas mehr Zeit, für einen ausführlicheren Kommentar:

Zitat aus einem anderen Forum:

Wenn Uwe das Programm schon so "deppensicher" angelegt hat, da wäre es sinnvoll, bei der Abfrage mit den eigenen Messungen die Schallwandmaße, Treiberposition, Treibergrößen etc. des Messobjekts abzufragen und genauso wie bei den Visatonchassis auf unendliche Schallwand rückzurechnen und dann bei Gehäuseänderungen umzurechnen.
So, wie es derzeit angelegt ist, sind SÄMTLICHE Berechnungen des Progs ausser dem Achsenfrequenzgang im Original(Mess-)gehäuse und dem Impedanzverlauf, möglicherweise noch der Phase für die Tonne...., sobald man andere Schallwandabmessungen eingibt, als bei der Messung verwendet.

Die elektrischen Frequenzgänge könnten auch noch hinkommen. Sonst ist das 100% richtig. Anders formuliert steht da: Wenn man in einem anderen Gehäuse als dem simulierten gemessen hat, aber angibt, in dem simulierten Gehäuse gemessen zu haben, dann stimmt das Ergebis nicht mehr. Boxsim ist bedauerlicherweise derzeit nicht in der Lage, Messungen aus einem beliebigen Gehäuse zu akzeptieren und gleichzeitig den Treiber in einem anderen Gehäuse zu simulieren. Ausnahmen sind lediglich die VISATON-Testboxen, die DIN-Schallwand und die unendliche Schallwand.

Wahrscheinlich sind auch die Winkelsimulationen im Messgehäuse nicht brauchbar, da vermutlich bestimmte Welligkeiten im Achsenfrequenzgang, die von Kantenreflexionen herrühren, falsch interpretiert werden, da keine Rückrechnung auf unendliche Schallwand stattfindet.

Unter der obigen Voraussetzung, dass das wirkliche Messgehäuse gar nicht dem angegebenen entspricht, sind natürlich auch die Ergebnisse zumindest fragwürdig.

Da dann aber auch weder der Energiefrequenzgang noch das Bündelungsmaß richtig berechnet wird (mach boxsim sowieso falsch), wäre es sinnvoller, bei Verarbeitung von eigenen Messungen alle anderen Berechnungen ausser dem Achsenfrequenzgang abzuschalten....
Wenn du dir mal den HT unter Chassis ansiehst, dann wird das deutlich: Da wird der wellige Frequenzgang der Achsenmessung als Halbraumfrequenzgang "verkauft"."

Zum Thema "macht Boxsim sowieso falsch":
1. Stimmt. Jede Simulation ist falsch, fragt sich nur um wie viel.
2. Es stimmt auch, dass es einen Fall gibt, in dem zwei unterschiedliche Chassisanordnungen, die in der Praxis genau den gleichen Energiefrequenzgang ergeben, in Boxsim bis zu 4,5 dB unterschiedliche Ergebnisse liefern. Das ist zwar ein Extrembeispiel, aber diesen Fall gibt es auch. Ich bestreite nicht, dass beim Energiefrequenzgang der Glaube an die Genaugkeit infolge der schwierigen Nachmessbarkeit vielleicht manchmal etwas zu groß ist. Eine deutliche Erhöhung der Anzahl der simulierten Richtungen wäre hier der Präzision sicherlich sehr dienlich.
3. Ich kenne keinen Fall, in dem Boxsim mit korrekten Eingaben wirklich unsinnige Ergebnisse liefert. Wenn Boxsim ein Loch im Energiefrequenzgang simuliert, dann ist da in der Regel auch eins, auch wenn es vielleicht etwas tiefer oder weniger tief ist.
Die zappeligen Frequenzgänge der Auf-Achse-Messungen werden genau dann als Halbraumfrequenzgänge "verkauft", wenn man angibt, es seien welche. Das habe ich eben nochmal verifiziert.

Dann haben wir mal probeweise andere Schallwandabmessungen im gemeinsamen Aussengehäuse und deutlich andere Treiberanordnungen der gemessenen Treiber eingegeben und sind dann zu folgender Einschätzung gelangt:

Zweites Zitat:

"Ja, war auch zu erwarten, da Summierung im unendlichen stattfindet.
Mit anderen Worten als Nachtrag zu meinem vorherigen Post:
Es ist wohl vollkommen egal, welche Schallwandabmessungen und Treiberpositionen man bei eigenen Messungen verwendet:
Die Achsensimu ist jeweils gleich korrekt, den Rest der Berechnungen incl. Energiefrequenzgang etc. kann man vergessen..."

Der Achsenfrequenzgang stimmt in der Tat auch dann wenn man zwar im gleichen Gehäuse Treiber und Box gemessen hat, in Boxsim aber ein anderes angibt. Den Rest kann man dann vergessen - stimmt.
Bei Messungen in der zu simulierenden Box sind Vorwärts- und Rückwärtssimulation der Schallwand identisch - sie werden aber definitiv durchgeführt. Deshalb sollten bei korrekter Eingabe der Schallwandmaße auch die Richtungsfrequenzgänge im Rahmen der Simulationsgenauigkeit stimmen. Wenn nicht, dann verstehe ich das gerade nicht.

Drittes Zitat:

"Auch das ist ausgezeichnet zusammengefasst und muss bei Simulationen mit
eigenen Messungen berücksichtigt werden:
Nur der Hauptfrequenzgang (Frequenzgang Gesamtbox) des selbst gemessenen
Lautsprechers ist korrekt und zwar für den Mikrofonmesspunkt.

Ein Schritt weiter:
Würde man ins Boxsim für den Hochtöner und den Tieftöner die 30-Grad Messung einpflegen,
dann würde Boxsim auch diesen Frequenzgang unter Frequenzgang Gesamtbox korrekt darstellen,
denn Boxsim verknüpft die eingelesenen Chassis-Frequenzgänge korrekt.

Für die anderen Winkelmessungen müsste man genauso verfahren.

Für eigene Messungen gilt
(Mikrofon ist während der Messung an einer festen Position):
Man müsste also für jeden Winkel ein Boxsim-Projekt anlegen, wenn man in Boxsim die korrekten Frequenzgänge unter Winkeln haben möchte."

Nach unseren Erfahrungen muß man also bei Verarbeitung von eigenen Messungen folgendermaßen zusammenfassen:

1.) Der Frequenzgang auf Achse wird korrekt simuliert, dabei ist es unerheblich, welche auch vom Messobjekt abweichende Schallwandgröße und Treiberposition gewählt wird.

2.) Auch mit der korrekten Schallwandabmessung des Messobjekts werden Ausser-Winkel Frequenzgänge und somit auch Energiefrequenzgang und Bündelungsverhalten falsch berechnet.

3.) Daraus folgt, daß man dann nicht auf einen Ausser-Achse-Winkel (wie z.B.) 30 Grad optimieren kann, da der Winkel wie auch alle anderen nicht korrekt simuliert wird.

Zusammenfassung: Boxsim ist darauf getrimmt worden, aus nur einer Messung auf Achse, alle Richtungsfrequenzgänge zu simulieren. Mit Messdaten für verschiedene Richtungen kann es nicht wirklich etwas Sinnvolles anfangen.

4.) Die Verwendung des Optimierers in der vorliegenden Form macht bei Projekten mit eigenen Messungen keinen Sinn, da all die umfangreichen Berechnungen eh nicht benötigt werden, falsch sind und völlig unnötige Rechenzeit kosten.

Dazu muss man wissen, dass der Begriff "eigene Messungen" in diesem Fall bedeutet, dass Frequenzgangmessdaten für alle Chassis in alle Richtungen vorliegen. SO pauschal, wie es hier gelesen werden kann, ist das Unfug.

5.) Will man auch auch Winkelmessungen von eigenen Projekten richtig simulieren, dann muß man für jeden Winkel ein eigenes Projekt anlegen und dann die Frequenzweichenbauteile per Hand in jedes einzelne Winkelprojekt übertragen.
Das geht aber selbst mit dem Methusalem Audiocad deutlich schneller und komfortabler.

Für mich folgt daraus, daß die Arbeitsweise des boxsim-Optimierers grundlegend verändert werden sollte. Wie, ist ja im Wesentlichen in entsprechenden Threads auch hier gesagt worden.
Als wichtigstes sollte der reine Optimierungslauf NUR mit dem Achsenfrequenzgang stattfinden und nur nach Abschluß der Optimierung der ganze Wust an anderen Berechnungen EINMALIG gemacht werden, allerdings nicht bei Projekten mit eigenen Messungen, da dann all die anderen Auswertungen eh überflüssig wie ein Kropf sind.
Das würde auch die bisher ätzend lange Laufzeit der Optimierung deutlich beschleunigen.

Zitat der Boxsim-Homepage: "Zielgruppe sind ambitionierte Lautsprecher-Selbstbauer, die bereits über grundlegende Kenntnisse zur Berechnung von Lautsprechern verfügen."
Wenn jemand in der Lage ist, Messdaten seiner eingebauten Chassis für alle Richtungen anzufertigen, dann spielt er für mich nicht mehr in der Hobby-Liga. Dort ist es schon viel, überhaupt eine sinnvolle Messung zustande zu bekommen. Wenn Entwickler Messdaten für alle Richtungen zur Verfügung hätten, wäre das ganze Konzept von Boxsim zu hinterfragen, nicht nur der Optimierer.