AW: AMD TrueAudio: Erste Hörprobe direkt aus Lichdom - Ihre Meinung?
Des weiteren sollte AMD meiner Meinung nach ganz einfache OpenAL HW Unterstützung anbieten und nicht eine eigene API bringen. Im Grunde das selbe wie mit Mantle, zwar eine Gute Idee, jedoch immer zu Lasten der Programmierer.
Wenn Mantle als Reihe von OpenGL Extensions und TrueAudio als OpenAL Extensions angeboten würden würd ich mir ne AMD Karte holen, nur aus dem Grund die zu Supporten. Aber so hinterlassen die Entwicklungen einen faden Beigeschmack.
/sign/sign/SIGN
Propietäre Schnittstellen können die Entwicklung nicht vorranbringen - siehe PhysX. Und da ist wenigstens nur die Leistung proprietär, von TrueAudio gibt es nicht mal einen CPU-Client
Es gibt einen guten Grund wieso das diese DPS direkt auf der Graka sitzen: die Umgebungeometrie.
Die Soundchips können so die komplette Gemetrie verwenden welche von der graka berechnet wurde, sprich es macht sogar einen unterschied wie gross der Raum am ende des Ganges ist durch den man gerade läuft.
mMn der nächste schritt wären dann Texturen für die Audioreflektion welche Materialeigenschaften wie Metal oder Schallschluckwände noch besser imitieren können.
Man könnte doch aber der Geometrie verschiedene Audioeigebschaften zuweisen, oder? Aktuell ändern sich ja auch die Geräusche, wenn man übe Beton statt Gras läuft.
Könnte - ja.
Kann - NEIN.
Den Sound tatsächlich auf dieser Ebene zu berechnen, dürfte bis auf weiteres unmöglich sein. Das wäre de facto eine Raytraycing-Engine, nur halt für andere Parameter. Es gibt Lösungen, die so arbeiten, aber für eine Echtzeit-Umsetzung müsste man die Mehrfache Rechenleistung der GPU selbst investieren, denn im Gegensatz zum optischen Raytracing, ist Streuung hier extrem wichtig und man müsste mit dutzenden sekundär und hunderten Tertiärstrahlen arbeiten. Da rettet auch die geringe Winkelauflösung am Ausgang die Leistung nicht mehr.
Und das ist nur der Aufwand für eine einfache Annäherung. In der Realität und im Gegensatz zu (Licht)Strahlen breiten sich Schallwellen kugelförmig aus (z.B. auch hinter Hindernisse) und interagieren im Raum.
In der Praxis dürften die Berechnungen so ablaufen, wie bei z.B. Creative auch: Soundsamples werden in einer bestimmten Entfernung in einer bestimmten Richtung abgespielt. Die Karte berechnet den Abstand und die Verteilung auf die einzelnen realen oder virtuellen Boxen und ggf. Verfremdungseffekte. (Wobei ich bislang nicht gehört hätte, dass True Audio eine fertige Bibliothek ala EAX anbietet. Effekte müssten also ggf. von jedem Entwickler selbst geschrieben werden)
Das einzige was zusätzlich wäre, wären eben die Audio-Oberflächen als Texturen, diese wären aber nicht sehr gross.
Eine Textur, die Reflektions- und Absorptionseigenschaften entlang des Frequenzspektrums wieder gibt, könnte durchaus eine gewisse Größe erreichen. Man kann zwar die Auflösung sehr niedrig absetzen, aber muss weit mehr als 3 Kanäle beachten. Und bei sehr vielen Substanzen muss man zwingend mit vielen Lagen/Subsurface-Scattering arbeiten, weil Sound nunmal so funktioniert.
Aber die Überlegungen sind sowieso müßig, da schlichtweg die Rechenleistung zur Simulation der komplexen Ausbreitung fehlt.
True-Audio ist etwas anderes als eine Soundkarte. Die Soundkarte wandelt den Digitalen Audiostream in einen Analogen um, True Audio kann einen solchen Digitalen Audiostrom auf der Grafikkarte erzeugen und von dort weitergeben.
Eine APU (ja, die Abkürzung ist älter, als der neumodische "accelerated"-Kram
) ala Live, Audigy oder Xfi übernimmt auch die Berechnung der Streams. Selbst bei einfachen Karten ist dies traditionell Aufgabe des Soundtreibers gegeben. Zwischen DOS und Vista jedenfalls...
Das die CPU dabei nicht beansprucht wird ist nicht der einzige Vorteil, auch Zeitlich lässt sich Sound, echo und co. nun besser abspielen.
Latenztechnisch dürfte es ein Rückschritt sein. Die Sounddaten müssen von der CPU zur GPU, von der GPU zur CPU und von der CPU zur Soundkarte. Das ist schon etwas mehr Aufwand, als nur CPU->Soundkarte.
Das wird 100% mit Kollisionsabfragen gemacht. Schon einzig aus dem Grund dass man die abfrage braucht damit der Spieler nicht durch den Boden fällt. Genau das ist mein Punkt. Viele der Kollisionsabfragen die man braucht werden sowieso schon gemacht. zb: Man nehme einen Shooter, wenn eine Waffe abgefeuert wird (und man keine Flugbahn braucht) (wie CS.S zb.) muss man nen Ray in Richtung der Waffe casten. Trifft dieser Ray zwar den Spieler, aber vorher ne Wand, so wird kein Schaden berechnet, diese Information kann man auch dazu nutzen den Sound der Waffe zu dämpfen. Und diese Information zu benützen ist Performance Technisch gratis.
Natürlich ist der Sound an die restlichen Berechnungen der Engine gekoppelt. Aber nicht jeder einzelne Ton an eine indidivuelle Kollisionsabfrage. Du hast jede Menge Geräusche, die dauerhaft oder zumindest regelmäßig erklingen -z.B. auch Schritte- und die schlicht an das Modell gebunden sein dürften.
Ich muß gestehen, ich weiß nicht, so EAX seine Daten herbekommt.
Jedenfalls durch das alles auf der SoKa berechnet.
EAX-Effekte werden vom Spiel (wahlweise über OpenAL oder DirectSound3D-Erweiterung, wo es noch DirectSound3D gibt...) angefordert. Das heißt das Spiel sagt, wo sich die Soundquelle befindet und was für Effekte in der Region gelten (z.B. Echo in einem Raum. Ab EAX3 sind auch mehrere Räume möglich). Die Soundkarte berechnet dann daraus, wie das Geräusch verändert wird und in welchem Winkel es den Charakter trifft bzw. was letzteres für die Verteilung auf die Boxen bedeutet.
Hoffen wir, dass es mit Win8 wieder Einzug findet.
