Eigene App zur Berechnung von Nachhallzeiten

Da ich im letzten Semester mit der Planung des Audiostudios der FH Joanneum beaufragt wurde, kam mir zunächst die Idee die Nachhallzeit der geplanten Umsetzung zu kalkulieren. Allerdings ist mir bei der Recherche nach einem geeigneten Tool aufgefallen, dass es keine kompakte Applikation gibt, die dies ermöglicht. Es gibt zwar komplexe Simulationssoftwares wie EASE der Firma AFMG Technologies GmbH, bei denen die Nachhallzeiten in einem 3D-Modell ermittelt werden und das Nachbauen eines Raumes mit einem großen Zeitaufwand verbunden ist, diese Softwarelösungen sind aber verhältnismäßig teuer und nicht im Sinne einer schnellen Nachhallzeitberechnung.
Da ich mich außerdem in meinem Project Work mit der Programmierung von Unity-Skripten in der Programmiersprache C# beschäftigt habe und tiefgreifendere Kenntnisse in dieser Sprache erlernen wollte, kam ich in den letzten Semesterferien auf die Idee, eine solche Applikation selber zu schreiben, um bei zukünftigen Projekten Nachhallzeitkalkulationen anbieten zu können. Außerdem wäre es in naher oder ferner Zukunft auch im Interesse aller Akustiker und Audioenthusiasten, eine solche Software zu veröffentlichen.

Grundsätzlich funktioniert die Applikation so, dass man zunächst die Maße des (rechteckigen) Raumes eingibt. Daraus wird das Volumen und die Oberfläche ermittelt, die für die spätere Kalkulation benötigt wird. Man wählt daraufhin das Oberflächenmaterial aus, aus welcher die Wände, Decken und Böden bestehen. Für die verschiedenen Materiale werden Oberflächengrößen eingegeben, die auch für die Kalkulation benötigt werden.
Im unteren Teil der Applikation wird nun nach dem Betätigen des “CALCULATE”-Buttons die Nachhallzeit in einem Graphen ausgegeben.

Prototyp des Programms

Behind The Scenes

Das Programm habe ich mithilfe des C#/XAML-Frameworks Avalonia geschrieben, das auf der Syntax des .NET-Frameworks WPF aufbaut, das für für User Interfaces entwickelt wurde. Der Unterschied zu WPF ist allerdings, dass Avalonia cross-platform ist und somit auch auf anderen Betriebssystemen als Windows ausführbar ist. Zusätzlich habe ich für die Applikation das MVVM-Konzept verfolgt, welches das User Interface streng von der Programmlogik und der Datenbank trennt. Dies ermöglicht in Zukunft leichtere Eingriffe in die verschiedenen Teilaspekte des Programms, wie z.B. des User Interfaces, ohne die Programmlogik verändern zu müssen.

Die Auswahl der Oberflächenmateriale geschieht über ein Dropdownmenü, welches eine Liste verschiedener Materiale aus einer aktuell noch provisorisch angelegten Datenbank ausgibt.

Dropdown-Liste mit unterschiedlichen Materialen

Die Datenbank wurde mittels SQLite angelegt und in das Programm implementiert. SQLite ist eine kompakte SQL-Lösung, die sich hervorragend für lokal angelegte Datenbanken eignet und ohne Webserver auskommt.

Datenbank mit Materialen in SQLite

Der Kern der Kalkulation basiert auf statistischen Nachhallzeitberechnungen nach Eyring bzw. Sabine, die ich in einem meiner früheren Blogposts bereits behandelt habe. Man kann manuell zwischen der Berechnung nach Eyring bzw. Sabine auswählen. Graphisch wird die Nachhallzeit mit dem .NET-Framework OxyPlot, das praktischerweise auch mit Avalonia kompatibel ist, ausgegeben.

Das Programm funktioniert bereits im Kern, es gibt allerdings noch einige Sachen, die überarbeitet und verfeinert werden müssen für eine professionelle Nutzung:

  • Erweiterung der Bänder der Absorptionsgrade von Oktavbändern von 125 – 4000 Hz auf Terzbänder von 50 – 8000 Hz
  • Option zum Umschalten zwischen 125 – 4000 Hz und 50 – 8000 Hz
  • Automatische Auswahl zwischen der Eyring und Sabine-Berechnung je nach gemitteltem Absorptionsgrad
  • Manuelle Skaliermöglichkeiten des Graphen
  • Plotten des Graphen als PDF oder JPEG
  • Vergleich von Graphen mit verschiedenen Oberflächenkonfigurationen
  • Fehlermeldung bzw. Warnung, wenn Oberflächen der Materiale größer sind als die gesamte Raumoberfläche
  • Speicher- und Lademöglichkeit der Raumkonfiguration und der Berechnung
  • Manuelles Einpflegen und Speichern von Materialdaten
  • Auslesen von Materialdaten aus Excel-, CSV-Tabellen und SQL Datenbanken.
  • Überarbeitung des User Interfaces

Quellen:

https://www.afmg.eu/en/ease-enhanced-acoustic-simulator-engineer

https://avaloniaui.net/

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm

https://oxyplot.readthedocs.io/en/latest/index.html

Kritische Bewertung der Diplomarbeit “Theoretische Planung und messtechnische Evaluierung eines Hallraumes”

Titel
Theoretische Planung und messtechnische Evaluierung eines Hallraumes

Hochschule
Technische Universität Graz

Betreuer
Dipl.-Ing. Herbert Hahn

Begutachter
Ao. Univ.-Prof. Dipl.-Ing. Dr. Gerhard Graber

Autorin
Jamilla Balint

Datum
März 2014

Gestaltungshöhe
Die Gestaltung dieser Diplomartbeit ist, wie bei vielen Arbeiten, die sich mit technischen Themen außeinandersetzen, eher schlicht und übersichtlich gehalten. Die Schriftart und die vielen Formeln deuten daraufhin, dass diese Arbeit mit LaTeX verfasst wurde.


Innovationsgrad
Das Thema an sich ist nicht besonders innovativ, da sie zur täglichen Arbeit eines Akustikers zählt. Interessant ist allerdings der Aufwand der betrieben wurde, um verschiedene Messpositionen und Szenarien zu bewerten. Daraus ergeben sich Erkenntnisse, die man in der Realwirtschaft und in der praktischen Berufswelt nur schwierig bekommen würde.


Selbstständigkeit
Die Autorin schreibt die Arbeit vollständig selbständig. Auch die praktischen Simulationen, Messungen und Auswertungen werden selbstständig erledigt. Lediglich der Hallraum wird von der TWB Buch GmbH zur Verfügung gestellt.


Gliederung und Struktur
Die Gliederung und Struktur ist meiner Meinung nach gut gelungen und folgt einem logischen Aufbau. Zunächst werden die theoretischen physikalischen Grundlagen geklärt, dann wird die Software zur Simulation des Hallraumes vorgestellt. Anschließend folgt die praktische Simulation und die Messung mit einer Gegenüberstellung und Bewertung der Ergebnisse.


Kommunikationsgrad
Die Thematik ist für einen Laien schwierig zu verstehen und geht tief in die Materie. Ohne physikalischen bzw. technischen Vorkenntnissen tut man sich schwer das Geschriebene außerhalb des Abstracts zu verstehen. Mit Vorkenntnissen hingegen lässt sich das Geschriebene gut nachvollziehen.


Umfang der Arbeit
Die Arbeit ist mit einer Gesamtlänge von 113 Seiten eher lang, allerdings nehmen die physikalischen Formeln, Abbildungen und Tabellen auch viel Platz in Anspruch. Auch ist der Umfang angemessen für den praktischen Aufwand und die Komplexität des Themas


Orthographie sowie Sorgfalt und Genauigkeit
Beim Lesen der Kapitel sind mir im groben keine grammatikalischen als auch orthographischen Fehler aufgefallen. Im Quellenverzeichnis sind mir allerdings Fehler wie “Sringer-Verlag Berlin” statt “Springer-Verlag Berlin” oder aber auch “Taschenbuch der Technichnischen Akustik” statt “Taschenbuch der Technischen Akustik” aufgefallen.


Literatur
Die meiste Literatur basiert auf anerkannter Fachliteratur. Allerdings findet man auch einige Referenzen zu Studienarbeiten (Diplomarbeiten, Bachelorarbeiten) der TU Graz. Ob diese den wissenschaftlichen Standards entsprechen, um in einer Diplomarbeit zitiert zu werden ist, müsste überprüft werden. Da wissenschaftliche Quellen bei so speziellen Themen oft rar sind, wird die Autorin wohl aus diesem Grund aus anderen Studienarbeiten zitiert hat. Die Literatur, mit welcher die Autorin arbeitet, ist überwiegend aktuell, wobei auch einige ältere Werke aus den letzten Jahrzehnten vorkommen. Da ich selber Akustiker bin, kann ich aus eigener Erfahrung sagen, dass in der Akustik im Laufe der Zeit neue Erkenntnisse hinzukamen. Diese bauen aufeinaner auf, statt alte zu widerlegen, weshalb ältere Werke im wesentlichen nicht an Relevanz verloren haben.

Quelle:

https://www2.spsc.tugraz.at/www-archive/downloads/DA_Balint_final.pdf

Das “Live-End, Dead-End”-Konzept im Studiobau

Im Bau und Konzeption von Regieräumen haben sich unterschiedliche Konzepte zum Umgang mit Reflexionen ausgehend von den Lautsprechern entwickelt. Besonders populär ist das sogenannte “Live-End, Dead-End“-Konzept (kurz LEDE). Dieses wurde Ende der 70er Jahre von Don und Carolyn Davis vorgestellt und in den darauffolgenden Jahren häufig umgesetzt. Aus eigener Erfahrung als Studioplaner kann ich sagen, dass Konzepte dieser Art ein wenig an Bedeutung verloren haben, weil Studios heutzutage eher funktional gebaut werden. Allerdings muss dazu gesagt werden, dass durch den massiven Rückgang der Verkäufe von Tonträgern auch die Budgets für teure Studiokonzepte und -umsetzungen fehlen.

Das LEDE-Konzept wurde unter der Beachtung psychoakustischer Effekte, wie dem Haas-Effekt und dem Richtungshören entwickelt. Dabei ist die Grundidee, dass der Regieraum in zwei Hälften geteilt wird. Der vordere Teil des Raums (Dead-End), wo sich auch die Lautsprecher befinden, ist komplett mit absorptivem Material verbaut, während die zweite Hälfte (Live-End), also die Rückwand und ein großer Teil der Seitenwände und Decke komplett reflektiv ist. Das Ziel ist es einen Direktschall zu erhalten, der sich hinsichtlich Prägnanz, Lautstärke und Zeit deutlich von den Erstreflexionen unterscheidet. Dazu wird die “Live-End”-Seite diffus gestaltet und der Schall so gestreut, dass man keine harten, diskreten Einzelreflexionen hat, welche den Klang zu sehr färben. Außerdem soll der Raum durch diese Maßnahme lebendiger und natürlicher klingen als typische Regieräume, die überwiegend mit Absorption bedämpft werden.
Um dieses Konzept noch zu optimieren, werden die Lautsprecher in die Frontwand eingebaut, sodass die kugelförmige Abstrahlcharakteristik tiefer Frequenzen unterbunden wird. Damit bleibt der vordere Teil des Raumes komplett reflexionsfrei.

Tonregie mit sbsorptiver Front und reflektiver Rückseite

Es gibt aber auch den Ansatz Tonregien genau andersrum zu gestalten. In diesem Fall wird der vordere Bereich reflektiv gebaut und die Rückseite absorptiv. Dabei werden potentielle Erstreflexionen von der Rückwand und den Seitenwänden absorbiert.

Tonregie mit reflektiver Front und fest verbauten Lautsprechersystemen

Welches Konzept sinnvoller ist, ist in vielen Fällen eine Frage des Geschmacks und des gewünschten Höreindrucks. Erst durch das längerfristige Arbeiten in beiden Arten von Räumen kann ein eigenes Urteil gefällt werden.

Quellen:

Philip Newell. 2012. Recording Studio Design. Third Edition. S. 391 ff.

https://www.soundonsound.com/techniques/sos-guide-control-room-design

Nachhallzeitenkalkulation in der Raumakustik

Um das Abklingverhalten eines Raumes zu beschreiben, wird der Begriff Nachhallzeit verwendet. Dieses bezeichnet die Zeit, in welcher ein Schallpegel um 60 dB abnimmt, nachdem die Schallquelle abgeschaltet wurde. Die Nachhallzeit ist dabei abhängig von der Raumgröße, der Raumgeometrie und der Oberflächenbeschaffenheit von Wänden, Böden und Decken. Nachhallzeiten verhalten sich im Frequenzspektrum nicht gleich, sondern unterscheiden sich, abhängig vom Oberflächenmaterial von Räumen, teilweise stark. Häufig brauchen tieffrequente Schallanteile länger um abzuklingen als hochfrequente.

Nachhallzeiten können zum einen gemessen, zum anderen aber auch berechnet bzw. simuliert werden, wenn die wesentlichen Variablen bekannt sind.
Zur Berechnung der Nachhallzeit finden in der Praxis zwei Formeln Verwendung. Die Eyring’sche und die Sabine’sche Formel.

Für eine Nachhallzeitenkalkulation nach Eyring wird das Volumen des Raumes V und die gesamte Absorptionsoberfläche A benötigt. Letztere wird durch Addition der einzelnen Absorptionsoberflächen, die sich wiederum aus der Multiplikation der jeweiligen Absorptionsgrade α und der Oberflächengröße der unterschiedlichen Oberflächenmateriale ergibt, berechnet.

Berechnung der gesamten Absorptionsoberfläche

Daraus kann der mittlere Absorptionsgrad α des gesamten Raums berechnet werden. Dafür die gesamte Absorptionsfläche A mit der Gesamtoberfläche des Raumes Sges dividiert.

Berechnung des mittleren Absorptionsgrades

Mit diesen Variablen kann nun die Nachhallzeit nach Eyring berechnet werden. Hinzu kommt die Energiedämpfungskonstante. 4mV beschreibt die Absorption von Schall im Medium Luft. Bei kleinen Räumen und nicht zu hohen Frequenzen ist diese allerdings vernachlässigbar.

Berechnung der Nachhallzeit nach Eyring

Schwach bedämpfte Räume, also Räume mit einem mittleren Absorptionsgrad von α < 0,25 werden mit der vereinfachten Formel von Sabine berechnet.

Berechnung der Nachhallzeit nach Sabine

Die Nachhallzeit wird nun für jedes einzelne Frequenzband (in der Regel Terz- oder Oktavbänder) berechnet, um ein frequenzunabhängiges Verhalten der Nachhallzeit bestimmen zu können. Solche Kalkulationen werden vor allem bei der Planung von Gebäuden insbesondere von Konzerträumen, Tonstudios oder Konferenzräumen benötigt, um richtige Entscheidungen bezüglich der Innenausstattung und der Auskleidung von Oberflächen treffen zu können.


Quellen:

https://www.soundandrecording.de/tutorials/studioakustik-die-nachhallzeit-im-studio/

David Tudor und die Merce Cunningham Dance Company

Der Choreograph und Tänzer Merce Cunningham gründete 1953 die Merce Cunningham Dance Company, die eine große Rolle in der Welt der performativen, modernen Kunst spielten. Weltweiten Erfolg erlangte die Tanzgruppe vor allem 1964 bei der sechsmonatigen Welttournee. Die Merce Cunningham Dance Company gab bis 2011 Aufführungen. 2 Jahre zuvor ist Merce Cunningham im Alter von 90 Jahren verstorben.
Die Werke der Tanzgruppe beinhalten eine Kombination verschiedener Medienformen, wie Fotografie, Film, Klang und natürlich der Live-Performance. Für dieses Projekt waren John Cage und David Tudor involviert als Komponisten. Die Kompositionen David Tudors für die Tanzgruppe basieren vor allem auf der Verwendung experimenteller elektronischer Elemente.

Eine der bekanntesten Werke, das David Tudor für die Merce Cunningham Dance Company vertonte, ist das im Jahre 1968 veröffentlichte “RainForest”. Für das Bühnenbild wurde Andy Warhols Installation “Silver Clouds” verwendet. Das sind silberne, mit Helium gefüllte Kissen, die in der Luft hängen und zufällig angeordnet sind. Während der Aufführungen verhielten sich die Kissen oft unberechenbar. Im Werk “RainForest” gibt es an sich keine Handlung, die Dramaturgie wird stattdessen durch die gesamte Atmosphäre geschaffen. Die Musik besteht aus elektronischen Klängen, Vogelgezwitscher und anderen Klängen von Tieren. Auch wurden verschiedene Objekte wie Tassen, Krüge, Vasen usw. zur Generierung von Klängen verwendet.

RainForest (1968)

David Tudor komponierte zum einen die Musik für einige Werke, gleichzeitig entwickelte er aber auch Systeme, die das interaktive Zusammenspiel der Tänzer mit der Musik ermöglichten. Im Werk “Variations V” entwarf Tudor zusammen mit Cage ein System, das den ausführenden Tänzern mithilfe von Lichtschranken ermöglichte, unterschiedliche Klangerzeuger zu steuern. Zusätzlich wurden Antennen auf der Bühne verteilt, die weitere Klänge steuern und manipulieren, sobald die Tänzer sich den Antennen nähern. Desweiteren wurden alle Requisiten elektronisch vernetzt, sodass auch diese Klänge generieren konnten. Damit wollten Tudor und Cage das standardmäßige Verhältnis, bei welchem der Tanz auf Musik folgt, aufbrechen und die Musik abhängig vom Tanz machen.

Variations V (1965)



Weitere Werke:

Exchange (1978)
Sounddance (1975)
Ocean (1994)

Quellen:
https://www.staatsoper.de/biographien/cunningham-merce

https://www.faz.net/aktuell/feuilleton/buehne-und-konzert/merce-cunningham-dance-company-es-war-einmal-in-amerika-11576852.html

http://www.see-this-sound.at/werke/189.html

https://www.mercecunningham.org/the-work/choreography/rainforest/

Wwise Implementierung in Unity (Teil 5: AkListener, AkGameObj & AkEnvironment)

In meinem letzten Blogeintrag habe ich das grundlegende Prinzip der Soundengine von Unity, die auf der Verwendung von Audio Listenern und Audio Sources basiert, vorgestellt. Die Wwise-Soundengine arbeitet auf dem selben Prinzip und hat standardmäßig bereits vorhandene Skripte mit welchen die selben System realsiert werden können. Diese Skripte heißen AkAudioListener und AkGameObj. AkAudioListener ist der Wwise-Ersatz für den Audio Listener von Unity.

Ist die Position und Blickrichtung eines GameObjects notwendig, was bei den meisten diegetischen Klänge einer dreidimensionalen Spielwelt der Fall ist, muss dieses GameObject auch als ein solches in Wwise registriert werden. Dafür gibt es das AkGameObj-Skript, das auf alle GameObjects gelegt wird.

Das GameObject, das als Main Camera dient und auf welchem das AkAudioListener-Skript liegt, muss ebenfalls mit einem AkGameObj-Skript versehen werden, weil auch dessen Position und Blickrichtung notwendig ist, um den Abstand und die Richtung zu anderen GameObjects berechnen zu können. In Wwise kann das Verhalten des Richtungshörens und auch des Pegelabfalls bei steigernder Distanz von Audio Listener zu klangerzeugenden GameObject (wie der Rolloff in Unity) konfiguriert werden.

Konfiguration des Klangverhaltens von Objekten in einer dreidimensionalen Spielwelt
Pegelabfallverhalten abhängig von der Distanz des Audio Listeners zum GameObject

Das AkGameObj-Skript kann zusätzlich auch noch andere Parameter aus dem Spiel übermitteln, wie Switches, RTPCs oder Umgebungsinformationen.

Reverb Zones werden Wwise mithilfe von Aux-Bussen realisiert, mit welchen innerhalb von Wwise ein Hall-Effekt zum Direktsignal hinzugemischt wird. Tatsächlich können auch andere Effekte statt Hall-Effekte verwendet werden. Das hierfür benötigte Skript ist das AkEnvironment-Skript, welches auf einen Collider gelegt wird. Im Inspector des Collider-GameObjects kann ausgewählt werden, welcher Aux-Bus aktiviert werden soll, sobald der Collider betreten wird.

AkEnvironment Skript, welches den “Testreverb” aktiviert

Dabei ist wichtig, dass das GameObject, wie z.B. der Audio Listener (also die Main Camera) im AkGameObj so konfiguriert wird, dass diese auf AkEnvironment-Skripte reagieren und damit ein Signal an den jeweiligen Aux-Bus senden.

Dieses GameObj ist Hall-fähig konfiguriert


Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Audio_Listener

[2] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_audio_listener.html

[3] https://www.audiokinetic.com/library/edge/?source=Unity&id=pg__wwise_components.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_game_obj.html

[5] https://www.audiokinetic.com/library/edge/?source=Unity&id=unity_use__ak_environment__ak_environment_portal.html

Audio Listener und Audio Sources in Unity

Eines der grundlegenden Prinzipien der Soundwiedergabe in der Gameengine Unity ist das Zusammenspiel aus sogenannten Audio Listenern und Audio Sources. Auf diesem Prinzip basieren alle mit Unity entwickelten Spiele und Klangrealisierungen. Man muss sich ein Spiel ein wenig, wie einen Film vorstellen, bei welchem der Regisseur (oder aber der Spieleentwickler) genau festlegt, was der Spieler sehen kann und was nicht. Zwar hat der Spieler viel mehr Freiheiten als im Film, aber im Grunde ist es ein ähnliches Prinzip. Auf visueller Ebene wird eine Kamera genutzt, die der Spieler lenken kann. Diese wird oft Main Camera genannt und ist oft an die eigene Spielfigur in der ersten oder dritten Person gebunden. Gesehen werden können alle GameObjects die im Blickwinkel der Kamera sind und mit sichtbaren Texturen belegt sind.

Ähnlich verhält es sich auch auf klanglicher Ebene. Analog zum Visuellen kann man Audio Listener als die Main Camera sehen und Audio Sources wie visuelle GameObjects. Tatsächlich ist der Audio Listener in den meisten Fällen mit der Main Camera verknüpft und Audio Sources mit den GameObjects, die Sound erzeugen. Der Audio Listener ist quasi ein Mikrofon, der Signale von Audio Sources erhält und weiter an die Audioausgänge schickt. In Unity kann es standardmäßig nur einen Audio Listener geben.

Audio Listener empfangen also Signale von Audio Sources, welche aber noch durch Effekte, wie z.B. einen Hall, geschickt werden können, wenn der Audio Listener sich in einer sogenannten Reverb Zone befindet. Reverb Zones sind kugelförmige GameObjects, die ein bestimmtes Gebiet umfassen und nach Eintreten des Audio Listeners den Anteil des Halls hinzumischen, je nachdem, wie nah sich der Audio Listener am Zentrum der Reverb Zone befindet.

Audio Reverb Zone im Unity Inspector mit verschiedenen Konfigurationsmöglichkeiten
Visualisierung des Hall-Verhaltens. Innerhalb des “Full Reverb”-Bereichs ist der Anteil des Diffussignals bei 100%. Im “Gradient Reverb”-Bereich sinkt der Anteil des Diffussignals zugunsten des Direktsignals, je weiter außen der Audio Listener sich befindet

Audio Sources können auf zwei Arten implementiert sein: 2D und 3D, diese können mit dem Spatial Blend-Regler reguliert werden.

2D bedeutet, dass sowohl Abstand als auch Richtung zum Audio Listener nicht relevant sind und der Sound unabhängig davon abgespielt wird. Der Sound, außer er wird im Unity-Mixer oder im Inspector des selben GameObjects noch weiter bearbeitet, wird so wie er ist abgespielt. Das wird vor allem für Soundtracks oder klangliche Hintergrundkulissen, wie Atmo-Aufnahmen, verwendet.

Audio Source mit verschiedenen Konfigurationsmöglichkeiten

3D hingegen setzt einen Sound Source in die dreidimensionale Spielwelt und erlaubt Richtungshören und zugleich variable Pegel, je nach Abstand des Audio Sources zum Audio Listener. Das Richtungshören wird ermöglicht, indem das ausgehende Audiosignal in ein Monosignal gewandelt wird und durch Pegelunterschiede ein Panning erhält. Es gibt zwar auch Lösungen für komplexere Surround-Sound-Verfahren, aber standardmäßig arbeitet Unity nur mit dieser vereinfachten Form, welches das Richtungshören ermöglicht. Von den verschiedenen 3D-Konfigurationsmöglichkeiten ist vor allem der Rolloff von großer Bedeutung. Damit lässt sich bestimmen, wie der Pegel, je nach Abstand zum Audio Listener, abfällt. Standardmäßig verwendet man entweder einen logarithmischen oder einen linearen Rolloff. Alternativ kann auch ein eigener, händisch eingezeichneter, Rolloff erstellt werden. Zusätzlich bestimmt man noch die Parameter Min Distance und Max Distance. Diese markieren einen Bereichen, in dem der Audio Listener sich befinden muss, um den Audio Source hören zu können und in welchem der Rolloff sich abspielt. Ist der Audio Listener außerhalb dieses Bereichs, wird das Signal nicht an diesen weitergegeben und folglich wird das Signal auch nicht abgespielt.

Die unterschiedlichen Rolloff-Verhalten

Quellen:

[1] https://docs.unity3d.com/Manual/class-AudioListener.html

[2] https://docs.unity3d.com/Manual/class-AudioReverbZone.html

[3] https://docs.unity3d.com/Manual/class-AudioSource.html

[4] https://docs.unity3d.com/Manual/AudioSpatializerSDK.html

[5] https://docs.unity3d.com/Manual/AmbisonicAudio.html

Wwise Implementierung in Unity (Teil 4: Scripting)

Neben der Nutzung vorgefertigter Skripte, die für die Implementierung von Wwise in Unity mitliefert sind, gibt es auch die Möglichkeit eigene Skripte bzw. eigenen Code zu schreiben, um Befehle an Wwise zu senden. Der Vorteil davon ist, dass man ganz genau bestimmen kann, an welcher Stelle Befehle an Wwise übermittelt werden sollen. Viele Funktionen werden außerdem von den mitgelieferten Skripten nicht abgedeckt und müssen deshalb selbst erstellt werden. Häufig muss z.B. ein Sound abgespielt werden, wenn ein Spieler eine Taste betätigt oder etwas im Spiel geschieht, was nicht mit Triggercollidern zu tun hat.

Für das Implementieren von Wwise in Unity mittels Skripte gibt es grundsätzlich zwei Möglichkeiten: Die direkte Hardkodierung eines Befehls oder die Kodierung mithilfe von Wwise-Types, die im Unity-Inspector einen Property Drawer anzeigen, mit welchem man Wwise-Objekte (Event, State, Switch usw.) auswählen kann.

Jeder hardkodierte Befehl beginnt mit dem Begriff AkSoundEngine, der quasi eine Information für Unity darstellt, dass ein Wwise-Objekt aufgerufen werden soll. Daraufhin wird bestimmt, welche Wwise-Funktion ausgeführt werden soll. Eine der grundlegendsten Funktionen ist “PostEvent” für das Aufrufen eines Wwise-Events. Desweiteren gibt es noch die Funktionen “setState” bzw. “setSwitch” zum Bestimmen eines States bzw. Switches, “setPosition“, damit Wwise die Position eines GameObjects bekommt, was für die korrekte dreidimensionale Wiedergabe von diegetischen Sounds benötigt wird, “setRTPC“, mit welchem Parameter aus dem Spiel an Wwise übermittelt werden und viele weitere Funktionen, die in der Wwise-Dokumentation nachgeschlagen werden können.
In den runden Klammern wird immer der Name des Wwise-Objekts als String mit angegeben. Manchmal werden noch andere Argumente benötigt, wie das GameObject, von dem der Befehl ausgeht.

Das Aufrufen eines hartkodierten Trigger-Events, das Sounds für Fußschritte abspielt

Alternativ dazu kann man auch mithilfe von Wwise-Types Implementierungen realisieren. Dazu wird zunächst eine Variable mit einer Wwise-Type-Klasse initialisiert. Wwise-Type-Klassen sind die verschiedenen Arten von Wwise-Objekten. Das ist z.B. AK.Wwise.Event für Wwise-Events, AK.Wwise.State für Wwise-States und viele andere. Auch alle Wwise-Type-Klassen können in der Wwise-Dokumentation nachgeschlagen werden.

Daraufhin kann im Unity-Inspector im Property Drawer des Skripts das jeweilige Wwise-Objekt, welches im Wwise-Editor angelegt ist, ausgewählt werden.

Variable “Play_SFX_Ellen_Run” mit dem gleichnamigen Wwise-Objekt im Property Drawer belegt


Nach der Initialisierung wird die Variable in einer Funktion im Skript aufgerufen. Dabei wird die Variable mit der jeweiligen Wwise-Funktion aufgerufen, wie z.B. “Post()” bei Wwise-Events oder “SetValue()” bei RTPCs, States oder Switches.

Variable “EllenFootsteps” wird mit Wwise-Type “AK.Wwise.Event” initialisiert und in der darauffolgenden Funktion “FootstepWwiseType()” mit der “Post()”-Funktion aufgerufen

Quellen:

[1] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Posting_Events_using_WwiseTypes#read

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Creating_a_WwiseType_Event_property#read

[3] https://www.audiokinetic.com/library/edge/?source=SDK&id=waapi_functions_index.html

[4] https://www.audiokinetic.com/library/edge/?source=Unity&id=annotated.html

Wwise Implementierung in Unity (Teil 3: AkState, AkSwitch)

Bei meinem letzten Blogeintrag habe ich die Wwise-Implementierungsskripte AkInitializer und AkBank, die eine grundlegende Voraussetzung für die Nutzung der Wwise Audio-Engine bilden und das Laden von Soundbanks ermöglichen, beschrieben.

Ein Grundbaustein eines adaptiven Sounddesigns ist das adaptive Verhalten von Sounds, das auf unterschiedliche Gegebenheiten im Spiel reagiert. Dafür gibt es Switches und States, die quasi Zustände repräsentieren und wie Schalter aktiviert werden können. Der Hauptunterschied zwischen Switches und States ist, dass ein Switch jeweils einem einzigen GameObject zugeordnet wird, während States von unterschiedlichen GameObjects aktiviert werden können. Die Nutzung und Konfiguration beider Parameter ist hingegen identisch.

Für das Verändern eines Switches oder eines States gibt es extra dafür vorgefertigte Skripte namens AkSwitch und AkState. In Wwise müssen dafür bereits die unterschiedlichen States bzw. Switches und die State bzw. Switch-Container mit den Audiofiles vorhanden sein, damit man sie in Unity implementieren kann. Ist das gegeben legt man ein AkSwitch- bzw. AkState-Skript auf ein GameObject. In diesen kann man nun über den Unity-Inspector den Switch bzw. State wählen, der aktiviert werden soll.

Auswahl des States im Unity Inspector

Des Weiteren muss noch bestimmt werden, was den Switch bzw. State triggert. Klassischerweise ist es das Betreten oder Verlassen eines Colliders.

Der State wird hier beim Verlassen des Triggers verändert

Hierbei sollte noch ein AkTriggerEnter– bzw. AkTriggerExit-Skript hinzugefügt werden, der spezifiziert, welches GameObject den Trigger auslöst, ansonsten löst jede Kollision mit irgendeinem anderen GameObject den Trigger aus, was in den meisten Fällen nicht gewünscht ist.

AkTriggerExit-Skript mit dem Player als auslösendes GameObject

Quellen:

[1] https://www.audiokinetic.com/library/edge/?source=SDK&id=soundengine_switch.html

[2] https://www.audiokinetic.com/courses/wwise301/?source=wwise301&id=Setting_States_using_the_AkState_Component

Wwise Implementierung in Unity (Teil 2: AkInitializer & AkBank)

Im letzten Blogpost habe ich die für Unity vorgefertigten Skripte AkEvent und AkTriggerEnter beschrieben, die in Kombination für das Auslösen von Wwise-Events genutzt werden. Dieses Mal möchte ich einige grundlegende Skripte zur Nutzung von Wwise vorstellen.

Damit die Unity-Engine allerdings überhaupt erkennt, dass es Wwise als Audio-Engine nutzen soll, muss zunächst Wwise beim Spielstart initialisiert werden. Das wird mit dem Skript AkInitializer realisiert. Hierfür wird ein leeres GameObject benötigt, das beim Starten des Spiels bereits vorhanden ist. Das GameObject wird im Inspector von Unity mit dem AkInitializer-Skript versehen, das automatisch beim Starten des Spiels geladen wird. Während des Spiels sorgt das Skript zusätzlich dafür, dass Frame für Frame Daten an die Wwise-Engine übetragen werden und somit die Kommunikation unter den beiden Engines gewährleistet wird. Das ist eine der Grundvoraussetzungen für die Nutzung von Wwise.

Leeres GameObject (links) mit AkInitializer-Skript (rechts)

Eine mit AkInitializer nah verwandte Funktion von Wwise ist das Laden von sogenannten Soundbanks. Soundbanks sind Audiodaten und Befehle, die während des Spiels in den Arbeitsspeicher geladen werden und somit unmittelbar ohne längeren Wartezeiten abgerufen werden können. Große Spiele arbeiten mit vielen Soundbanks, die abhängig von der Position des Spielers oder anderen Bedingungen einzeln geladen und wieder entladen werden. Das ermöglicht die Realisierung von großen und komplexen Spielwelten auf einem PC oder einer Konsole. Häufig wird vom Entwicklerteam ein Datenmengenlimit vorgegeben, welches das Audio-Team nicht überschreiten darf.

Das Skript für das Laden von Soundbanks heißt AkBank und kann an unterschiedlichen Stellen ausgeführt werden. In der Regel hat man immer eine Soundbank, die beim Starten des Spiels geladen wird. Weitere Soundbanks werden unter anderem geladen, wenn ein neues Gebiet betreten wird. Das Laden einer Soundbank dauert eine Weile, weshalb einige Spiele währenddessen eine Ladesequenz anzeigen. Bei der praktischen Anwendung erfordert das Skript im Unity-Inspector eine Information, wann die Soundbank geladen, wann sie entladen werden soll. Dabei muss auch bestimmt werden, welche Soundbank geladen werden soll. Es gibt noch weitere Optionen, mit welchen sich einstellen lassen, wie dekodiert und wie genau mit den Daten verfahren werden soll. Das hilft beim Datenmanagement und ist vor allem für umfangreiche Spiele mit großen Datenmengen praktisch.

Die Soundbank “Footsteps” wird beim Starten des Spiels geladen und beim Zerstören des GameObjects entladen

Quellen:

[1] https://www.audiokinetic.com/library/edge/?source=Unity&id=class_ak_initializer.html

[2] https://www.audiokinetic.com/library/edge/?source=WwiseFundamentalApproach&id=understanding_soundbanks_understanding_soundbanks