Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Gut, Problem 1 (inline) und 3 (seeking) habe ich deinen Vorschlägen entsprechend umgebaut. Problem 2 konnte ich noch nicht beheben/nachvollziehen. Kommentiere mal in der commons_conf.inc den Schalter DO_NOT_USE_VCL aus und erzeuge das Projekt nochmal neu. Schaue ob dann der Fehler immernoch auftritt. Wenn das nicht hilft, muss ich versuchen den Fehler irgendwie zu reproduzieren...
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
So, ich habe nochmal genau geschaut und den Fehler beheben können. Jedoch müsstest du nochmal drüber schauen, da ich nicht weiß, ob irgendwelche Threads folgendes vielleicht doch nicht so ganz optimal machen.
In der Datei Au3DAudio.pas habe ich die Methode TAu3DAudio folgendermaßen angepasst:
Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Ja, du hast recht, der Code muss so ergänzt werden. Ich habe das überprüft. Problem ist, dass meine Filtergraph-Filter nur über diesen "Target"-Pointer miteinander verbunden sind und ein Filter keinerlei Informationen über seinen Vorgänger hat. Da mir das schon einige Probleme beschert hat, werde ich das wohl für die nächste Version ändern.
So weit schon mal vielen Dank für die Fehlermeldungen und Fixes, so detailierte Beschreibungen findet man nicht alle Tage!
Andreas
EDIT: Habe eine neue Version hochgeladen, alle von dir beschriebenen Fehler sollten behoben sein.
Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Hallo,
Flash hat geschrieben:
Durch die Kindemitter willst du dann die Schallreflexion abbilden oder?
Genau. Hierduch entstehen automatisch Effekte wie Echo, Reverb etc. Ziel der Bibliothek ist es, eine möglichst wirklichkeitsgetreue Simulation zu schaffen. Bei Spielen wie Oblivion oder Fallout 3 (mehr Spiele habe ich nicht *g*) ist mir immer wieder aufgefallen, dass das Augenmerk kaum auf der Audiowiedergabe gelegen hat. So hört man Leute durch Wände hindurch laut und deutlich reden und im kleinsten Raum hört sich jede Unterhaltung genauso an, wie in der freien Wildbahn. In Zeiten, in denen (fast) jeder Spiele-PC mit vier Prozessorkernen ausgestattet ist, von denen sich jedoch zwei langweilen, soll Audorra für etwas (sinnvolle) Beschäftigung sorgen.
Flash hat geschrieben:
Vielleicht kannst du ja andere moderne Methoden die man zur Licht/Shattenberechnung einsetzt für die Schallberechnung verwenden. Eventuell könntest du sogar einen Shader bauen, welcher dir deine Welt in den Farben deiner Soundquellen rendert. Keine Ahnung ob sowas effektiv wäre.
Darüber habe ich mir auch schon gedanken gemacht, jedoch bin ich zu dem Schluss gekommen, dass ich überhaupt gar keine Hyper-Realistische Simulation für sehr viele "Audixel" (Audio-Bild-Elemente) brauche. Ich schätze, dass der Overhead für das hin und her Kopieren der Daten zwischen Grafikspeicher und Hauptprozessor größer ist, als für ca. 1000 Strahlen alle paar Sekunden Raytracing durchzuführen.
Noch ein kleines Update: Gerade bin ich dabei das Programm (oder Teile daraus) mkfilter (http://www-users.cs.york.ac.uk/~fisher/mkfilter/) in Pascal und OOP zu übertragen, sodass ich selbst Koeffizienten für meine IIR Filter berechnen kann. Um den OOP-Overhead und das Nachschlagen von Koeffizienten zu minimieren, habe ich vor komplette Filter "Just in Time" in SSE optimierten Binärcode zu kompilieren - mal schauen ob das was wird.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Selbst wenn man die Threading API gleich auf zieht und gleiches tut hat man unter Windows und Linux verhaltensunterschiede. Zum einem ist es Geschwindigkeit, wärend Windows Threads brechend lahm sind, sind die Linux threads überdimensional schnell. Dies und der Fall, dass man vieleicht irgendwo pointer, variablen oder anderes shared die nicht korrekt gesynct werden kann man erleben, das es unter Windows geht und unter Linux nicht. Das Spiel hab ich auch schon ein paar mal durch. Was da helfen kann sind Atomic Operation, welche Platformunabhängig sind und viel eleganter und schneller sind als normale mutex,critical section lösungen.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich hab heute mal aus langeweile und dem Drang, irgendwas mit Visualisierungen und OpenGL zu machen, einen genaueren Blick auf Audorra geworfen.
Nach ein bisschen Hick-Hack hab ichs dann auch unter FPC zum kompilieren bekommen (in einer Unit fehlt noch das $mode delphi und noch ein paar andere kleinigkeiten, wie das nicht-konditionale einbinden der Windows-Unit). Allerdings endete der Versuch, eine .ogg-Datei abzuspielen in etwas, das wie eine Mischung aus drei bis vierfache Geschwindigkeit und massivem Clipping klang. Außerdem war die gefühlte CPU-Last ziemlich hoch und ich konnte die Anwendung nicht in den Pulseaudio-Clients sehen, auch nicht über das ALSA-Interface. Also da scheint noch irgendwas nicht ganz rund zu laufen.
Stehe für Debugging zur Verfügung.
greetings
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Respekt! Deine Dokuverwaltung sieht gut aus und macht schon was her. Doxygen und GraphViz machen sich da sehr positiv bemerkbar.
Zwecks Sprachersatz für PHP. Wenn man Java kann ist Struts+JSP ne feine Sache. Da bekommt man dann die selbe Toolunterstützung wie beim normalen Javaprogrammieren und kann Sachen wie in PHP machen.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Das Stimmt, aber die Zusammenfassungseite wird automatisch aus den Unitnamen generiert und die Software weiß schließlich nicht für was die Abkürzungen stehen.
Registriert: So Mai 11, 2003 10:36 Beiträge: 285 Wohnort: Oldenburg
Programmiersprache: Object Pascal
Zitat:
Das Stimmt, aber die Zusammenfassungseite wird automatisch aus den Unitnamen generiert und die Software weiß schließlich nicht für was die Abkürzungen stehen
Achso.... Wäre aber bestimmt nicht schlecht, wenn man das irgendwie ändern könnte.
Dein CMT gefällt mir gut... Wie liegen die Daten vor ? in XML ? Hast du fpDoc genutzt ?
_________________ MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich hab gerade mal wieder etwas mit Audorra gemacht. Hauptsächlich habe ich meinen alten FMOD-Test entstaubt und versucht ihn auf Audorra zu portieren. Screenshots vom Ergebnis gibts hier:
Läuft ziemlich echtzeitig, nur manchmal laggts (die Spectrum history ist daher im Moment leider nicht Zeitlinear). Das Bottleneck liegt aber glaube ich eher in der grafischen Darstellung als in Audorra. Ein bisschen schneller könnte es aber dennoch sein, 80% Kernlast für die Aktion muss nicht sein. FMOD braucht für die Sache "nur" 60% (in Wine), klingt aber, wie ich gerade feststelle, deutlich schlechter (das kann aber auch an wine liegen).
greetings (wer errät, was ich jeweils auf den Screenshots abgespielt habe (alles drei unterschiedlich) bekommt pro Treffer einen Keks )
Edit: Just to clarify: Oben gab es keine verwertbare Aussage über die Geschwindigkeit von Audorra gegenüber FMod, da das Zeichnen wohl die meiste Performance zieht und bei den beiden verglichenen Anwendungen auf unterschiedliche Weise geschieht. Aber es gibt eine Aussage, dass Audorra deutlich besser klingt als FMod in Wine
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Hallo,
ich kann bestätigen, dass die Performance von Audorra unter Linux allgemein schlechter als unter Windows ist - aus welchem Grund auch immer. So läuft die Simple Demo auch auf meinem neun Jahre alten PIII 900Mhz Laptop samt FFT-Analyse bei (50FPS) und Zeichnen mit "nur" 20% CPU-Auslastung. Unter Linux kommt das gleiche Programm auf meinem Core2Duo auf über 60% Auslastung, unter Windows dümpelt das Programm zwischen 0-1%.
Ich denke, dass die meiste Performance aber wirklich für das Zeichnen draufgeht - so ist unter Linux das Canvas einfach nicht sonderlich optimiert und das Blitten dauert ziemlich lange.
Eigentlich "Idlen" auch alle Audorra-Threads wenn möglich vor sich her und geben ihre Zeit mittels "Sleep(1)" an den Scheduler ab. Da das Ganze aber auf niedrige Bufferzeiten und damit möglichst geringe Latenzzeiten optimiert ist, kommt es bei hoher Belastung des Systems öfter als bei einfachen Media-Playern, die oftmals mit Buffer-Zeiten im Bereich von Sekunden arbeiten, zu ausetztern.
Ich versuche dies jedoch in der nächsten Version zu optimieren.
Andreas
PS: Die Visualisierungen sehen Klasse aus, verwendest du die mitgelieferten Analyse-Klassen oder hast du eigene geschrieben?
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.