[Guide] OpenAL Soft mit HRTF als Ersatz für OpenAL (Vorteil: 3D Sound für Headphones)

IRCAM Ordnerstruktur:
Code:
IRC
├── COMPENSATED
│   ├── MAT
│   │   └── HRIR
│   └── WAV
│       ├── IRC_<number>_C
└── RAW
    ├── MAT
    │   └── HRIR
    └── WAV
        ├── IRC_<number>_R
In den HRIR Ordnern liegt jeweils eine `IRC_<number>_R_HRIR.mat` Datei. In den `IRC_<number>_R` Ordnern liegen zahlreiche wav Dateien.

Meine Erfahrung mit IRCAM-HRTFs war mittelmäßig. So habe ich dort zwar einen mehr oder weniger runden Kreis mit dem richtigen Preset hören können, aber ingame konnte ich Objekte zwischen Positionen "springen" hören. Deswegen nutze ich wieder das Standard-HRTF Set, das mit OpenAL Soft geliefert wird. Dieses scheint höher aufgelöst zu sein.

Ich behaupte einfach mal, dass die meisten Spiele mit DirectSound3D oder OpenAL Höheninformationen liefern. Was die Unreal Engine 1 angeht, so gibt es dafür einen Community Patch, der Unterstützung für OpenAL hinzufügt und meiner Erinnerung nach Höheninformationen bietet.

Man kann eigene Matrizen für Ambisonics mit der Ambisonics Decoding Toolbox erstellen. Ambisonics funktioniert unter Linux prinzipiell mit beliebig vielen Lautsprechern in beliebiger Aufstellung. Allerdings ist es technisch aufwendig, das einzurichten. In diesem Guide gibt es mehr Infos. Für die Zukunft hoffe ich darauf, dass es dank MPEG-H einfacher werden könnte.
Surround Systeme mit mehr als 7.1 Lautsprechern könnten mit OpenAL etwas anders eventuell auch unter Windows funktionieren, aber da bin ich mir nicht sicher. Wichtig ist, dass man einen Audioserver wie JACK oder Pipewire nutzen muss, damit man beliebig viele Audiokanäle routen und ausgeben kann. Prinzipiell funktioniert das so: OpenAL rendert in Ambisonics und reicht das Ergebnis an ambdec weiter. Dieses berechnet aus dem Ambisonics Signal die einzelnen Signale für die konfigurierte Anzahl an Lautsprechern. Diese Lautsprechersignale werden von ambdec an den Audioserver weitergegeben. Der Audioserver routet diese Signale dann auf Audioausgänge. So könnte man mehrere Soundkarten gleichzeitig nutzen, um z.B. mehr als die üblichen 7.1 Signale ausgeben zu können.
Unter Windows könnte es vielleicht mit ASIO funktionieren.

Die im Video gezeigte Virtualisierung von 7.1 Surround Sound für Kopfhörer ließ sich meines Wissens nach vor Pipewire (neuer Audioserver) auch schon mit Pulseaudio (Vorgänger) erreichen. Allerdings muss ich gestehen, dass ich sie nie ausprobiert habe.

Dynamischen Raumklang, d.h. mit Echtzeitberechnung gibt es leider selten abseits von ein paar Forschungsprojekten wie GSOUND. Es gibt allerdings Mods für die GZDoom Engine (LiveReverb) und Minecraft (Sound Physics Remastered), die Echtzeit-Reverb integrieren. Bei OpenArena gab es auch mal einen Versuch, das zu integrieren. Vermutlich gibt es auch noch ein paar Implementierungen in anderen Spielen. Für Hinweise wäre ich dankbar. Die Verfügbarkeit von hardwarebeschleunigtem Raytracing lässt darauf hoffen, dass sich in Zukunft mehr in diesem Bereich tun könnte. Nier:Automata scheint ebenfalls dynamischen Reverb zu haben, habe es aber selbst noch nicht gespielt.
Allerdings sind Halleffekte nicht alles, was man für authentisches Audio braucht. Viele Spiele haben Audio Occlusion implementiert (Dämpfung durch Wände), Audio Obstruction (direkter Weg durch Hindernisse versperrt) vielleicht schon weniger. Path Tracing (Geräusche aus anderen Räumen werden nicht über den direkten Weg geortet, sondern z.B. durch Türen) findet man auch ab und zu, z.B. in der Thief Reihe.
Was mir häufig fehlt, ist eine realistische Modellierung der Distanz. Bei größeren Distanzen fallen die hohen Frequenzen im Vergleich zu niedrigen Frequenzen stärker ab, was das Gehirn neben anderem zum Bestimmen der Distanz ausnutzt. Spontan fallen mir Dragon's Dogma: Dark Arisen und ET:Legacy ein, die mir eine gute Einschätzung der Distanz erlauben.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Besten Dank für die Ordnerstruktur! Mal sehen, vielleicht brauche ich sie später ja noch - wie gesagt bin ich jetzt auch auf dem AmbiSonics Weg, denn wie Du schon richtig sagst, ist die Immersion wesentlich besser als mit HRTF.

Also Unreal1 liefert definitiv keine Höheninformationen (siehe auch meinen Thread auf oldunreal), wo Smirf überhaupt erstmal überlegen muss, wie er das implementiert.
Und darum geht's mir hauptsächlich, weil das der einzige Titel ist, der mich bei den alten Klassikern interessiert. Dass ähnlich alte Titel (und auch neuere) Höheninformationen liefern, würde mich sehr stark wundern, weil das bis vor Kurzem überhaupt noch kein Thema war (vor Dolby Atmos).
Was der Community Patch allerdings schon macht, ist eine Art surface occlusion detection, aber im Moment noch sehr rudimentär implementiert, mit einfachem Volume ohne Filter, etc.
Was mich bei der Unreal Engine 1 schon immer am meisten gestört hat ist, dass die einzelnen Sounds nicht besonders akkurat wiedergegeben werden (der community patch optimiert ja nur die Positionierung), will heissen die Fade-curve eines Radius wird nicht sauber zu Ende gerechnet. Und das haut die ganze Audio-Immersion zusammen.

ok, was Du dann beschreibst, klingt äusserst vielversprechend, funktioniert so aber nur unter Linux. kCat arbeitet aber angeblich schon an einer Lösung/Tools, die diese Berechnungen für die Settings hoffentlich sehr vereinfachen werden. Im Moment wäre ich schon froh, wenn ich mit AmbiSonics 8 horizontale Lautsprecher nutzen könnte; was ich aber an solchen custom matrices nicht verstehe ist, wie das dann in der ini (oder in der GUI dafür) eingestellt werden soll (Win7-10), weil diese Matrix ja auch mit Namen definiert werden muss, und wo kommt der her (?)
Die Links muss ich mir noch durchsehen. Ich bin ja schon nah dran, mir extra für Unreal ein Linux aufzusetzen, GsD läuft der Patch ja jetzt auch mit einem Linux64 direkt.

Gerade zum bevorstehenden Release von Unreal Redux sollten sie sich die Audio Seite der Engine doch noch mal genauer vornehmen, weil die jetzige Implementierung wird der immensen Arbeit von Krull0r bei weitem nicht gerecht imo.
 
Möglicherweise habe ich missverstanden, was du mit Höheninformationen meinst. Ich habe es bisher so interpretiert, dass Spiele Klänge nicht nur 2-dimensional sondern 3-dimensional berechnen. Man kann bereits mit HRTF hören, dass viele alte Spiele Klänge in 3D berechnen. Es bietet sich ja auch an, wenn die Spielwelt schon in 3D vorliegt. Klänge werden meist an (teilweise sich bewegende) 3D-Objekte im Raum angeheftet und es gäbe kaum einen Grund, die Klänge nicht in 3D zu berechnen.
Bei OpenAL Soft funktioniert es ja z.B. so, dass OpenAL die 3D Koordinaten der einzelnen Klänge erhält sowie die 3D Koordinaten des Spielers und dann aus diesen Informationen das Ambisonics Soundfield in 3D berechnet bzw. gleich mit HRTF rendert.
Unreal habe ich nicht mehr installiert und seit vielen Jahren nicht mehr gespielt. Möglicherweise täusche ich mich, was dort das Berechnen der Klänge in 3D angeht.

Was du mit der Fade-curve ansprichst, scheint genau dem zu entsprechen, was ich mit der realistischen Modellierung der Distanz meinte. Viele Spiele haben keine realistische Fade-Curve und auch keinen Abfall der höheren Frequenz abhängig von der Distanz. Ich denke, dass das teilweise eine bewusste Entscheidung ist, um besser festlegen zu können, welche Dinge ein Spieler aus seiner näheren Umgebung hören soll und welche nicht. Ich stimme aber zu, dass es der Immersion nicht zuträglich ist.

In der alsoft.ini muss der Pfad zu der `.ambdec` Datei angegeben werden, der die Matrix enthält. Also unter Linux bspw.
Code:
surround51 = $HOME/itu5.1-nocenter.ambdec

Wenn du 8 Lautsprecher hast, müsstest du den `surround71` Eintrag anpassen. Dieser wird automatisch aktiv, wenn in den Systemeinstellungen 7.1 konfiguriert ist. Allerdings bin ich mir nicht sicher, ob man so 8 Lautsprecher (also nicht 7 LS + 1 Subwoofer) ansprechen könnte. Falls das nicht gehen sollte, bliebe nur der Weg, unter drivers auf `jack` oder eine Windows Alternative zu stellen und bei channels z.B. `ambi2` anzugeben. Entsprechend müsste dann mit JACK o.ä. die Ausgabe von OpenAL an ambdec weitergeleitet werden sowie die Ausgabe von ambdec wiederum an die Lautsprecher gereicht werden.
 
Mit Höheninformationen meine ich, dass anders als zB beim Auro3D Receiver (heisst glaub ich so), der eine ständige "Kulisse" auf die Deckenlautsprecher rechnet, die er aus den horizontalen Daten gewinnt, der Toplautsprecher nur dann aktiv wird, wenn auch ein entsprechendes Höhen-Event vorliegt.
Im Klartext muss der tönen, wenn ein Vogel *über* mir oder *unter* mir fliegt (also über oder unter der Horizontal-Ebene; unter mir wahrscheinlich nur mit Occlusion...), sonst nicht.
Er *muss* auch tönen, wenn ich den Kopf mit der Maus nach oben oder unten bewege, denn der Vogel ist trotzdem über/unter mir, egal ob ich den Kopf bewege oder nicht (anders als in der Horizontal-Ebene!)
So gesehen berechnen alle Engines nur "2-dimensional", weil sie nur die Horizontal-Ebene abgedeckt haben. Alles andere hätte auch keinen Sinn ergeben, weil selbst wenn sie es in die Engine eingebaut hätten, keiner einen Nutzen daraus ziehen hätte können (bei den Speakern gar nicht, bei HRTF eine Teilmenge nicht), und kein Entwickler verschwendet Zeit auf Dinge, die die meisten eh nicht, oder nur schlecht nutzen können (ausser Carmack, dem war sowas schon immer wurscht, aber auch Doom3 hatte keine Höhen-Info).
Wenn sie es tatsächlich in der Engine intern *vorbereitet* hatten, mussten sie es später trotzdem wieder auf die horizontale Ebene herunterbrechen. Dem Vogel werden dann zwar die 3D-Koordinaten angeheftet, letztendlich bewegt er sich aber trotzdem nur auf einem horizontalen 360 Grad Kreis hin und her.

Selbst wenn ich entscheide, dass der Spieler bestimmte Sounds nicht hören soll, würde es ja nichts daran ändern, dass der Rest immer noch korrekt berechnet werden muss. Ausnahmen vom Design her kann ich als Entwickler ja immer machen, aber die Wiedergabe sollte auf jeden Fall immer stimmig sein, und das ist sie nicht, wenn praktisch kein Sound richtig ausblendet. Erst wenn das einmal richtig funktioniert, kann man sich Gedanken über das Filtering machen, das ist dann die nächste Stufe. Natürlich bedeutet das einen höheren Rechenaufwand, weil die Sounds dann je nach Situation länger stehenbleiben, und ich sie nicht einfach wegschneiden kann (distance cueing), aber das sollte mit heutigen Prozessoren das geringste Problem sein.

Der Pfad ist auch in Windows so. Ist das bei AmbiSonics dann ein "Universal-Algorithmus", der nur eine AmbDec Konfiguration entgegennimmt? (dann hab ich das falsch verstanden)
Ich dachte, 7.1 legt die Matrix fix fest, und das man die auch mit einem anderen Preset nicht ändern kann. Das AmbDec Tool gibt's ja so weit ich weiss leider nur für Linux.
 
Ich bin kein Experte, was Auro3D angeht, aber dort muss man zwischen dem Upmixer `Auromatic`, der aus 2D Klang 3D Klang unter Ausnutzung der Höhenlautsprecher schafft und Auro3D, einem Übertragungsformat für 3D Klang unterscheiden. Bei letzterem oder vielleicht sogar beiden könnten die Toplautsprecher auch stumm bleiben. Das hinge von der Mischung ab, bzw. von der Arbeitsweise des Upmixers und dem Quellmaterial.

Grundsätzlich tönt bei Ambisonics _immer_ aus _allen_ Lautsprechern etwas (allerdings unterschiedlich gefiltert). Das liegt an der Arbeitsweise von Ambisonics. Der Entwickler hatte festgestellt, dass dies aufgrund psychoakustischer Phänomene die Lokalisation verbessern kann. Meiner persönlichen Meinung nach ist Ambisonics auch tatsächlich dem ansonsten verbreiteten Pan-Pot Panning für Surround überlegen. Ein 360° Panning von Klängen klingt mit Ambisonics einfach etwas runder und springt nicht so offensichtlich von Lautsprecher zu Lautsprecher. Speziell bei einem 5.1 System ist meinem Gefühl nach die Ortung zur Seite hin so auch etwas besser.

So wie du die Verarbeitung der Höheninformationen beschreibst, hängt es von der Behandlung der Zuhörerposition in der Engine ab, was letzten Endes aus den Toplautsprechern tönt. Es gibt vielleicht Spiele, die es so handhaben, wie du es beschreibst. Ich persönlich bevorzuge den Ansatz, dass der Zuhörer an die Kamera gebunden ist. Aus meiner Sicht ist das der realistischste Ansatz, weil ich den Kopf im Spiel neigen kann, aber es in der Realität nicht tue und dass Audiosystem das entsprechend kompensieren muss. Es gibt auch einige Spiele, die den Zuhörer an den Avatar binden, was bei einigen Kamerafahrten oder der Third-Person Perspektive auffällt.
Wenn ich dich richtig verstehe, müsste in deinem Fall der Zuhörer an den Kopf des Avatars gebunden sein, aber die Kopfneigung sollte nicht berücksichtig werden.

Tatsächlich spart die Klangberechnung bei den meisten Spielen einiges aus der Realität aus. Es ist ganz interessant, den OpenAL Effects Extension Guide zu lesen, um einen Einblick zu erhalten, was theoretisch alles möglich wäre. Dort werden auch so Dinge angesprochen, wie z.B. dass die Luftfeuchtigkeit den Klang beeinflusst und somit eine Wüste anders als eine Nebelbank klingen müsste.
Ich kenne kein Spiel, dass die Möglichkeiten von EAX bzw. EFX komplett ausschöpft. Allerdings sind auch die typischen Halleffekte nur eine Annäherung an die Realität. Für korrekte Hall-, Occlusion- und Obstructioneffekte müsste Raytracing eingesetzt werden.

Das Ambdec Format ist eins von (wahrscheinlich) mehreren zur Definition von Lautsprechermatrizen für Ambisonics. OpenAL Soft unterstützt nur(?) dieses, wahrscheinlich weil Ambdec freie Software ist und die Formatspezifikation somit frei zugänglich gewesen ist.

Der Parameter `surround71` gibt an, welche Ambisonics Decoding Matrix genutzt werden soll, wenn in den Systemeinstellungen die 7.1 Ausgabe eingestellt ist. Die Lautsprecheraufstellung für die Matrix könnte dabei weit von der klassischen 7.1 Aufstellung abweichen, das wäre kein Problem. Ich weiß nur nicht, ob man mehr als 7 Lautsprecher darüber sinnvoll ansprechen könnte. In einem Paper von Codemasters habe ich gelesen, dass man die Center und Subwoofer Kanäle generell nicht für normale Lautsprecher nutzen sollte, da diese Kanäle in Receivern gesondert gefiltert werden könnten.
 
Kurz vorab: Ich hab jetzt mal kurz die OpenAL Docs überflogen, und du hast recht: Die Sounds werden tatsächlich per x,y,z Koordinaten übertragen. Jetzt versteh ich überhaupt nichts mehr.
Wozu braucht man dann überhaupt eine zusätzliche Programmierung? Entweder übertragen die ständig nur x,y,0 oder die Titel waren von Beginn an Höhen-tauglich, man hatte aber keine Devices für die Wiedergabe, und es lag einfach brach. Damit könnte es ja jeder Shooter, der im Audio Setup OpenAL anbietet.
Du hast nicht zufällig Lust, Unreal unter Linux mit deinem jetzigen Lautsprecher-Setup zu testen? Ich kann es nicht, weil die Höhe der LS-Ständer davon abhängt, ob er die Höhenachse tatsächlich anspricht oder nicht (Hexagon oder 3D7.1). Ausserdem habe ich noch kein AVX2 System für 227j.

Wenn du den Kopf im Spiel hebst, in der Realität aber nicht, und du verlangst von der Engine, dass sie das kompensiert, dann hast du die Situation, dass beim Kopfheben um 90 Grad nach oben der Vogel aus den Frontlautsprechern kommt, und das kann wohl nicht Sinn der Sache sein. Die Horizontale muss kompensiert werden, die Vertikale darf es nicht.

ok, das heisst also soviel wie: "system setting = use matrix xyz". Also hat das Setting in Windows hier nur Informationswert, und bedeutet nicht, dass er das tatsächlich nutzt.
Ich meinte ja, sollte es so in Windows nicht funktionieren, bin ich sogar bereit mir Linux näher anzusehen.
Von deiner Erfahrung her: Wie kompliziert ist es wirklich, das mit AmbDec einzustellen, sprich wie lange sitzt man an so einer neuen Matrix?
 
Tatsächlich werden die Koordinaten nicht nur von OpenAL, sondern auch von vielen anderen 3D-Audio Schnittstellen als 3D Vektor erwartet. Dies gilt auch für DirectSound3D. Es ist auch bei einer Wiedergabe mit einem 2D System sinnvoll, die 3. Dimension zu berücksichtigen. Denn ansonsten würde z.B. ein Helikopter, der direkt über einem aufsteigen würde, immer gleich laut wiedergegeben werden, auch wenn er sich immer weiter entfernen würde.

Die Notwendigkeit für weitere Programmierung in Richtung Dolby Atmos liegt nur darin begründet, dass es momentan abseits der proprietären 3D-Audioformate keinen Übertragungsstandard für Audio mit Höhenkanälen im Konsumentenbereich gibt. Ambisonics B-Format existiert seit Jahrzehnten und hätte dies Lücke füllen können, konnte kommerziell aber bisher leider nie richtig durchstarten.
Wenn man mit einem Surroundsystem Spiele spielt, dann stellt man häufiger fest, dass diese die Rearspeaker teilweise auch für besondere UI Klänge oder andere Effekte nutzen, die keinen direkten Bezug zur 3D Welt haben. Höhenlautsprecher böten hier eine weitere Möglichkeit für die Gestaltung solcher Effekte. Da diese Klänge nicht an 3D Objekte in der Spielwelt gebunden sind, müssen sie gesondert programmiert werden.

Was das Ausprobieren von Unreal angeht: Installieren könnte ich es, ich habe die Höhenlautsprecher des 4.1.2 Setups aber momentan nicht mehr aufgebaut, da es von der Handhabe her sehr unpraktisch gewesen ist (ich nutzte 2 Soundkarten und 2 separate Verstärker, da ich nur einen 5.1 Receiver und einen Stereoverstärker hatte, insbesondere die Lautstärkeregelung war nicht optimal). Den Stereoverstärker habe ich auch nicht mehr. Ich habe die Hoffnung, dass es bald die Möglichkeit geben wird, über MPEG-H oder eine andere Schnittstelle beliebig viele Kanäle an einen Receiver aus dem Konsumentenbereich zu übertragen.
Ich würde stattdessen vorschlagen, dass du mal probierst, mit HRTF auf Höheninformatinen zu lauschen, oder du fragst im Oldunreal Forum nach, ob der OpenAL Treiber 3-dimensionale Positionsdaten übermittelt. Die dritte Alternative wäre, mit Tracing oder Software wie CheatEngine zu schauen, was das Spiel denn genau übermittelt...

Man kann sich sicherlich darüber streiten, ob die Vertikale kompensiert werden sollte oder nicht. Aus meiner Sicht übernehme ich die Rolle des Avatars und will die Dinge so sehen und hören wie er es tut. Tatsächlich könnte ich mir vorstellen, dass dein Ansatz zu Verwirrung führen könnte. Angenommen, du würdest einen Vogel anvisieren wollen. Wenn du ihn auf dem Bildschirm sähst, würdest du sein Geschrei über dir hören. Du könntest ihn blind so nicht anvisieren.

Das Erstellen der Matrix ist eigentlich relativ simpel, wenn man in der Lage ist, einfachen Matlab Quelltext zu verstehen (ich hatte vorher auch noch keinen Kontakt mit MatLab Quelltext). Bei ADT wird aus MatLab Quelltext eine Matrix berechnet. Es kommt mit zahlreichen Quelltextbeispielen. Ich habe mir einfach das Beispiel, das meiner eigenen Konfiguration am nächsten kam, kopiert und ein bisschen angepasst (größtenteils durch Ändern der Winkel). Man muss sich auch kein MatLab installieren, die freie Software GNU Octave ist mit dem Quelltext kompatibel.
Solange man auf die Nutzung von JACK und Ambdec verzichtet, was möglich wäre, solange man 7.1 oder weniger Kanäle nutzt, würde sich der Aufwand in Grenzen halten. Sobald man JACK und Ambdec mit einbezieht, wird die Einrichtung deutlich komplizierter, aber man könnte damit eben auch beliebig viele Lautsprecher mit Ton versorgen. Im ersten Fall müsstest du auch unter Windows ohne größeren Aufwand zum Ziel kommen.

Die Einstellung in Windows zu den Ausgabekanälen sorgt dafür, dass die Soundkarte so konfiguriert wird, dass sie beispielsweise 7.1 Kanäle ausgibt. Das nutzt OpenAL Soft dann aus, um decodiertes Ambisonics über diese Kanäle zu schicken.
 
Zuletzt bearbeitet:
Das Berücksichtigen der 3. Dimension ist mir schon klar, aber ich habe mir vorgestellt, dass sie innerhalb der 3D-Koordinaten die Höhen-Differenz feststellen, und dann einfach die Volume regeln. Genauso wie ich dachte, dass die Übergabe der Positionsdaten über Winkel stattfindet, d.h. Front=0, Back=180, links=negativ, rechts=positiv. Also ähnlich wie bei AmbiSonics bei der LS-Aufstellung auch. Bei Vertikaldaten wäre 0 dann genau vor mir, 90 wäre genau über mir, positiv wäre oben, negativ wäre unten. Die Engine würde dann aber teilweise die Arbeit von OpenAL übernehmen.

Nein, bei weiterer Programmierung meinte ich die Notwendigkeit, den z-Vektor von x,y,z überhaupt erst integrieren zu müssen. Das fällt (nicht nur bei OpenAL) ja dann sowieso weg.
Mit Konsumentenbereich meinst du die Receiver? Die würde ich persönlich ja nicht verwenden. Ich gehe direkt von der Soundkarte in Aktivlautsprecher. Gerade für Surround im Gamingbereich lege ich da keine Heimkino-Massstäbe an, da reicht ein ALC-1220 auf dem richtigen Mainboard locker aus. Sollte ich tatsächlich ein grösseres Setup benötigen, kommt ohnehin nur eine meiner Studio-Hardware in Frage, weil alles andere keine zB 24 Kanäle wird aufbringen können.
Das mit den UI-Sounds stimmt zwar, aber ich gehe davon aus, dass die ohnehin gesonderte Aufrufe verwenden; gibt ja genug Möglichkeiten dafür in OpenAL.

Stichwort MPEG-H: Du kannst damit vielleicht beliebig viele Kanäle an einen Receiver schicken, bist dann aber in der Anzahl der Endstufen begrenzt. Ich will die Signale von AmbiSonics so verstärken, wie sie aus der Soundkarte kommen (siehe unten).
HRTF funktioniert auf meinen Ohren offenbar nicht. Im oldunreal war man der Ansicht, dass die gesamte z-Achse erst implementiert werden muss, und das obwohl die reinen 3D-Sounds komplett mit allen Koordinaten ja schon von Stunde Null an in OpenAL eingebaut sein sollten. Zumindest den Docs vom Creative OpenAL aus 2009 nach, die kompletten Docs vom (abwärtskompatiblen) OpenAL-Soft suche ich noch (...), kann mir aber nicht vorstellen, dass das da plötzlich anders gehandhabt wird. Und da ist die x,y,z Methode die einzige, mit der man einen 3D-Sound anmelden kann, wenn ich das richtig verstanden habe.

Bezüglich Vertikalachse: Lass mich überlegen. Nein, ich denke nicht, dass man in meinem Beispiel nicht so sieht und hört wie der Avatar. Es gibt ja nicht nur eine Soundquelle zur selben Zeit. Wenn vor dem Avatar zB ein Gegner steht, und er gleichzeitig in den Himmel schaut, kommt der Gegner ja deswegen nicht plötzlich aus dem Bodenlautsprecher. Beim Anvisieren bin ich allerdings geneigt, dir recht zu geben, d.h. letztendlich ist es der Spielmechanik geschuldet, dass man die Vertikalachse dann doch kompensiert. Also kommen die Sounds immer aus der Richtung, in die ich die Waffe halte. Man kann sich hier ohnehin nichts wünschen, weil OpenAL ziemlich sicher in jedem Fall kompensieren wird. Obwohl ich nicht ganz verstanden habe, wie die zwei Vektoren der Kopfhaltung des Listener genau funktionieren.

Was die Matrix angeht: Zuerst bin ich ja von einer rein horizontalen Aufstellung ausgegangen, und da decken acht Lautsprecher den ganzen Kreis mehr als ab, vor allem wenn man bedenkt, dass AmbiSonics, wie du auch sagtest, sehr gut dazwischen "blendet". Davon ausgehend stellt sich mir die Frage (und das ist jetzt alles rein theoretisch), wieviele Lautsprecher der obere und der untere Kreis benötigen würden (zB. vier), und in welcher Aufstellung. Also an den Ecken (quad), oder doch zwei für vorne und hinten, und zwei an den Seiten (Raute).
 
Ich habe auch über die Möglichkeit eines Audiointerfaces und Aktivlautsprechern für Ambisonics nachgedacht, letzten Endes war mir Komfort dann aber doch wichtiger und da steht man mit Heimkinoausrüstung aus meiner Sicht besser da, insbesondere, wenn man an das System auch noch Blurays und Spielkonsolen anschließen möchte.
Natürlich ist die Anzahl der Endstufen bei Receivern begrenzt, aber ich könnte bei mir aktuell sowieso keine 15 Lautsprecher unterbringen (ich nutze nur identische Regallautsprecher in üblicher Größe), was dem derzeitigen Maximum im Konsumentenbereich entspräche.

Es würde mich wundern, wenn Unreal nicht schon bereits im ungepatchten Zustand mit dem Galaxy Audio Renderer, der DS3D nutzt, die z-Achse mit an die Audiobibliothek übergäbe.
Ich glaube, dass OpenAL Soft momentan keine richtige Dokumentation hat. Es gibt hier ein paar Infos und ansonsten noch Beschreibungen zu den neu eingeführten Erweiterungen.
Die beiden Kopfvektoren in OpenAL beschreiben einerseits die Hör-/Sehrichtung und andererseits die Richtung, in die die Spitze des Kopfes zeigt. Letzteres wird benötigt, um zwischen oben und unten zu unterscheiden.
OpenAL kompensiert die Vertikale meines Wissens nach nicht nach eigenem Gusto. Das Ergebnis hängt davon ab, welche Vektoren an OpenAL für den Zuhörer übergeben werden.

Mit einem Hexagon sei man bei Ambisonics bereits sehr gut für die horizontale Ebene gerüstet. Du bräuchtest vermutlich keine 8 Lautsprecher für die horizontale Ebene. Für die höhere Ebene empfehlen sich wohl mindestens 4, besser vielleicht 6 Lautsprecher. KCat meinte, diese sollten idealerweise 30° über der horizontalen Ebene angeordnet sein, allerdings weiß ich nicht, ob sie zu den Bodenlautsprechern versetzt oder darüber angeordnet werden sollten. Ich würde zwecks Kompatibilität mit anderen Formaten aber auch mal das One-For-All-Setup anschauen.
Für den Anfang könntest du auch mal die 3D7.1 Aufstellung probieren.
Ich selber konnte aufgrund meiner technischen Ausstattung nur mit zwei Höhenlautsprechern experimentieren. Ich habe mehrere Aufstellungen ausprobiert. Z.B. auch eine mit einem Lautsprecher vorne und einem hinten. Diese hatte einen zeltähnlichen Höreindruck zur Folge. Man kann mit Ambisonics definitiv witzige Sachen machen (auch ein schiefes/eingeknicktes Zelt habe ich hinbekommen :d)... Ich würde jedoch mehr als 2 Lautsprecher empfehlen, da ich damit nie eine geschlossene Hörkugel erreichen konnte (ich habe sie allerdings auch nicht an der Decke über mir aufgehängt, denke aber, dass dann die Winkel zu den anderen Lautsprechern auch zu groß geworden wären).
 
Zuletzt bearbeitet:
Ich wollte bis vor kurzem eigentlich überhaupt keine Lautsprecher mehr und dachte, die ultimative Lösung wäre HRTF (mit einer X-Fi und einem K1000), nachdem ich die Preise von Kopfhörer und zugehöriger Endstufe gesehen habe, der X-Fi und zwei Lautsprechern. Was aber weder so noch so funktioniert, weil es auch noch keine Presets für HRTF mit Lautsprechern gibt. Und das alles, weil ich mir die Verkabelung ersparen wollte, und jetzt bin ich erst wieder bei Lautsprechern gelandet :-) Allerdings haben die Edifier fast schon die Grösse von Satelliten, dazu ein kleinerer Subwoofer.
Die grosse Anlage hat dann die "richtigen" Lautsprecher mit 5.1, wird aber nur für Musik genutzt, Heimkino hab ich gar keins. Ich steh eher drauf, das alles voneinander zu trennen, dafür aber dann für jeden Einsatz einen Spezialisten zu haben. Gaming ist bei mir seit je her fast ausschliesslich Spielhalle (bin kein klassischer PC und Konsolen Spieler), dafür gibt's dann eben eigene Rechner, Flipper mit 9 Lautsprechern, oder eben Unreal Arcade (alles mit zig selbstgebauten Controllern).

OpenAL wurde so weit ich weiss erst 2003 eingeführt, da gab es die 226er schon einige Zeit, d.h. die Implementierung dürfte erst mit 227a stattgefunden haben, und das war so um 2007/2008.
Ich wüsste nicht, wie ich bei 227j/k die Höheninformationen so komfortabel übergeben könnte, wie mit OpenAL-Soft/AmbiSonics, wenn überhaupt. FMOD eignet sich ja eher für HRTF (2 Speakers), als für Multi-Speaker, bei Galaxy wüsste ich jetzt auch keinen Weg.
Wenn ich allerdings jetzt schon eine Kompensation in der horizontalen Achse habe, die mit den Kopf-Parametern gesteuert sein muss, ist es sehr naheliegend, dass auch die vertikale Achse kompensiert wird, das hab ich gemeint. Die ändern den Teil der Engine sicher nicht mehr.

ok, ich werde dann mal wohl mit einer 3D7.1 anfangen, vorher muss ich aber noch die Ständer schnitzen und einen neuen Teppich auslegen...
 
Ich war lange Zeit von HRTF begeistert, aber als ich mal ein gutes Surroundsystem (das vor allem richtig aufgestellt war) probehören durfte, war ich doch erstaunt, wie viel räumlicher und authentischer das klingen kann. Seitdem höre ich generell kaum noch mit Kopfhörer, da mir vor allem die Räumlichkeit sehr fehlt. Die Präzision bei der Ortung und teilweise auch die Auflösung fällt zwar im Vergleich zu Kopfhörern mit HRTF schlechter aus, aber ich finde das Gefühl einfach cool, wenn das Zimmer auf einmal nach einer Kirche und nicht mehr einem Zimmer klingt. Auch ist es ein anderes Gefühl, wenn man den Bass am ganzen Körper spürt.

Mein Ziel war es, ohne Behandlung der Raumakustik möglichst günstig ein Heimkino auf nahezu Referenzniveau zu erlangen. :d Mit Blick auf Ambisonics war mir wichtig, dass ich nur identische Lautsprecher verwende. Dies wird für Ambisonics empfohlen, da Ambisonics anders als bei Pan-Pot Panning auch die Phase nutzt, um den Höreindruck psychoakustisch zu verbessern und es bei ungleichen Lautsprechern weniger gut funktionieren soll. Deswegen habe ich mich für 8 (vergleichsweise) günstige Regallautsprecher, die bei Audiosciencereview sehr gut abgeschnitten haben sowie einen Studiosubwoofer entschieden, der bis 18Hz spielt. Klanglich bin ich begeistert, das System klingt sehr neutral und die Räumlichkeit ist sehr gut. Ich habe noch zwei Studiomonitore auf dem Schreibtisch zum Vergleich. Diese lösen noch etwas besser auf, aber dieser Eindruck könnte auch einfach durch den geringeren Hörabstand bedingt sein.
Von meinen Lautsprechern sind 4 aktuell in ihrer Verpackung, da ich mich noch nicht zum Kauf eines modernen Receivers durchringen konnte. Ich warte gespannt, ob es eine Möglichkeit geben wird, abseits von Dolby Atmos vom PC aus Audio mit Höhenkanälen an die Receiver zu liefern, da der PC meine hauptsächliche Quelle ist. Momentan würden Dolby Atmos und Co. wahrscheinlich unter Linux/Wine auch gar nicht funktionieren.

Bezüglich HRTF Presets für Lautsprecher: Die gibt es meines Wissens nach schon, bei Aureal A3D und Sensaura3D z.B.. Bei Sensaura3D gibt es sogar Multidrive HRTF, das 5.1 (oder war es 4.0?) Surroundsysteme voll für HRTF ausnutzt. Ich frage mich bis heute, ob die originale Xbox Multidrive HRTF integriert hat, da sie einen Sensaura3D Chip enthält und 5.1 Ausgabe unterstützt. Habe aber selbst nie eine zum Testen gehabt.

Bei älteren Unreal Versionen müsste man über den Galaxy Audio Treiber und DSOAL+OpenAL Soft auch Ambisonics beziehen können. Eventuell nutzt der Linuxport auch seit jeher schon OpenAL.

Dein Szenario klingt ungewöhnlich aber auch sehr interessant. Lass mich auf jeden Fall wissen, wie es ausgeht.
 
Mir fällt ein: Gab es nicht eigene Hifi-taugliche Ambisonics Receiver? (bilde mir ein, bei den Recherchen im Netz irgendwas gesehen zu haben) Die konnten das B-Format native wiedergeben.
Abseits davon sehe ich nur Hardware aus meinem Bereich (Studio) im Wesentlichen fürs Encoding (sauteuer).

Sensaura: Es müsste 4.0 gewesen sein. Laut kcat ist der Center bei diesen Anwendungen eher störend. Es soll ja auch ein hexagon mit Center nachgereicht werden, gleichzeitig mit dem Hinweis, dass es jedenfalls mit Einschränkungen verbunden sein wird.
Was Sensaura auf der XBox1 betrifft: Also ich war damals live dabei, und habe sowohl die XBox1 als auch das A7N8X. Die originale XBox verwendet eine modifizierte Southbridge vom nForce2, die einen DD-Stream (bis 5.1) in Hardware enkodieren konnte (ready to use für Receiver, ein geniales Stück Hardware, auch heute noch). Ich kann mich nicht erinnern, dass da noch ein zweiter Chip verwendet wurde; möglicherweise war der "DSP" mehr oder weniger frei programmierbar, und Sensaura wurde in Software realisiert. Die Specs listen Sensaura ja auch nur als "vorhanden", das kann genauso gut Software sein.

Du sagst es selbst: ältere Versionen. Ausserdem ist Galaxy in Unreal auf Status "deprecated", d.h. schon länger erledigt. Alle aktuellen Änderungen ("tons of fixes") beziehen sich nur mehr auf OpenAL oder auf FMOD. Das ist natürlich alles keine wirkliche Option.

Ich muss doch noch darauf zurück kommen: Du sagst, dass der erste Eintrag in der ini die Einstellung in Windows Audio beschreibt. Das ist ja dynamisch, je nach installierter Hardware/Kanälen.
Beispiel: Wenn ich einen Realtek Onboard aktiviere (7.1), meldet der Treiber an Windows "8 Kanäle verfügbar", Windows schreibt also "7.1" zur Auswahl als *maximale* Kanalanzahl. Natürlich kann man auch weniger verwenden, also zB. 5.1, aber das Maximum ist 8. Soweit richtig?
Jetzt installiere ich eine Hardware mit z.B 16 Kanälen. Keine Ahnung, was Windows dann hinschreibt, mglw. "mehr als 7.1 verfügbar", wobei das aber nicht sehr spezifisch wäre. Wahrscheinlich schreibt er bei einer Dolby Atmos Hardware "Dolby Atmos 7.1.4". Wäre auch mit Realtek möglich mit Jack Re-tasking -> 6 Klinken*ausgänge*. Was auch immer, egal.
Irgendein Eintrag muss auf jeden Fall dort stehen, und damit stellt sich das Problem (zumindest in der Windows-Version von OpenAL-Soft), dass ich für diesen Eintrag keinen entsprechenden Eintrag in der ini vornehmen kann, weil dafür ja gar kein Name definiert sein kann.
Natürlich kann ich wie du sagst, ein Preset zweckentfremden (ich muss dann halt die Ausgänge wie auch immer umleiten), aber immer nur im Rahmen der maximalen Kanalanzahl, die darin definiert wurde. Das wären im Moment 12 Kanäle (bei 7.1.4).
Das verleitet mich zu der Annahme, dass kcat zwar Ambisonics in OpenAL-Soft integriert hat, allerdings nicht in der vollen Ausprägung (Ambisonics ist ja eigentlich nur ein Sheet/Paper mit Formeln, die Umsetzung bleibt dem jeweiligen Programmierer überlassen).
In der jetzigen Version habe ich aktuell: quad, rectangle, 2x itu5.1, hexagon, 7.1.4, und 3D7.1. Wie sieht das bei dir in Linux aus?
Kann es sein, dass das Ding im Moment schlicht und einfach gar nicht mehr kann, als maximal 12 Kanäle?
 
Es gab Decoder für Ambisonics und ich meine auch von ambisonicsfähigen Receivern gelesen zu haben. Allerdings glaube ich, dass die meisten nur für 2D Wiedergabe geeignet sind und teilweise nur fest vorgegebene Dekodiermatrizen zur Auswahl anbieten.

Laut White Paper hat es Sensaura Multidrive sowohl für 4.0 als auch 5.1 gegeben. Ich dachte, ich hätte irgendwo gelesen, dass die XBOX Hardwarebeschleunigung für 3D Sound hätte und dass sie dafür einen Sensaura Chip nutzen würde.
Men of Valor ist wohl das einzige Spiel für PC, das Sensaura's HRTF für Lautsprecher auch auf dem PC durch eine Softwarelösung bietet. Ich habe es bisher allerdings nicht geschafft, mehr als ein Stereosignal aus dem Spiel zu bekommen (probiert mit Linux+Wine).

Mehr als 7.1 Kanäle sind mit OpenAL Soft möglich, aber dann muss der Umweg über Ambdec+Audioserver gegangen werden. Sobald man einen Audioserver verwendet, haben die Systemeinstellungen zumindest unter Linux keinen Einfluss mehr auf OpenAL Soft, da der Audioserver diese ignoriert und umgeht. Bei Linux gibt es in den Systemeinstellungen für Pulseaudio auch nicht mehr als 7.1 zur Auswahl.
OpenAL Soft muss für mehr Kanäle so konfiguriert werden, dass es undekodiertes Ambisonics (B-Format) an den Audioserver übergibt, der es wiederum an Ambdec leitet, welches ein dekodiertes Signal an den Audioserver zurückgibt, der dieses Signal dann über ein oder mehrere Audiointerfaces mit beliebig vielen Ausgängen an die Lautsprecher weiterleitet.
 
Sensaura: ok, dann scheint das bei HRTF anders zu funktionieren. Bei den letzten drei Ambisonics-configs wird der Center explizit nicht angesteuert.

sorry wegen der doppelten Erklärungen, aber ich denke, ich hab's jetzt einigermassen kapiert. Das ist ähnlich wie die Frame-Server der Videoschnittprogramme früher.
Muss mich jetzt mal auf die Reise begeben, und das alles zusammensuchen.

Es wird zwar eine Weile dauern, aber sobald ich neue Erkenntnisse habe, melde ich mich hier wieder, damit andere auch was davon haben.
 
Der Center wird unabhängig von Ambisoncs vielfach nicht für 3D Audio genutzt, da er häufig eine andere Bauform und damit einen leicht unterschiedlichen Timbre im Vergleich zu den restlichen Lautsprechern haben könnte sowie er häufig auf einer anderen Ebene steht. Das würde bei Schwenks von Klängen über die Frontbühne zu merklichen Sprüngen führen. Bei Ambisonics könnten sich ggf. Phasenunterschiede durch die abweichende Bauform zusätzlich negativ auswirken.
Meist soll der Center für Dialoge freigehalten werden. Es gibt aber auch Audioengines, die einen Center auch für 3D Audio nutzen und man könnte sich auch problemlos eine eigene Ambisonics Matrix erstellen, die den Center mit einbezieht. Von dem was ich gelesen habe, sollte man ihn für Ambisonics aber nicht an der üblichen Position zwischen den Frontlautsprechern nutzen, da der Winkel zu den Frontlautsprechern zu klein wäre, was sich negativ aufs Klangbild auswirken könnte.
 
Ich habe mir jetzt einen modernen Receiver mit Unterstützung für 9.2 gekauft und ein 4.1.2 System installiert, mit 2 frontalen Höhenlautsprechern. Für ein 4.1.4 System fehlt mir momentan leider der Platz.
Meine Erfahrung kurz zusammengefasst:
- Die beiden frontalen Höhenlautsprecher lassen einen sehr schnell 2 hintere Höhenlautsprecher vermissen, da Höheneffekte, die sich von vorne hinter den Hörenden bewegen, auf die hinteren Lautsprecher abstürzen.
- Der Dolby Surround Upmixer macht einen guten Job dabei, Halleffekte auszuweiten und die Räumlichkeit größer/überzeugender klingen zu lassen
- Was die Ortung von 3D Effekten angeht, bringen die frontalen Höhenlautsprecher alleine mMn nicht so viel, aber die zusätzliche Räumlichkeit ist schon nett

Ich habe auch temporär ein 4.1.3 System mit einem zusätzlichen Rear Height Center ausprobiert. Dieses lässt sich noch mittels Ambisonics per HDMI und 7.1 PCM ansprechen. Der Rear Height Center verbessert Halleffekte (EAX/EFX) und damit die Räumlichkeit nochmal deutlich. Das ist wirklich ein tolles Gefühl.
Geht es allerdings um die Ortung von sich bewegenden Objekten, so lässt auch der Rear Height Center sehr schnell 2 hintere Lautsprecher vermissen. Die Höhenebene wird gut genutzt, solange die Objekte in etwa auf der Linie zwischen der Mitte der Front Heights und dem Rear Height Center verlaufen. Zu den hinteren Seiten hingegen "fallen" Effekte dann auf die untere Lautsprecherebene, was Immersion kostet.
Das 3D7.1 Layout habe ich nicht getestet, da ich dafür einiges im Zimmer umstellen müsste und mir die volle Kompatibilität zu Stereo und 5.1 auch zu wichtig ist.

Neuere Wine Versionen unterstützen leider kein OpenAL Passthrough mehr. Bei alten Versionen wurden OpenAL API Aufrufe an das Host-Betriebssystem weitergereicht und dort von der Linux-nativen OpenAL Bibliothek bearbeitet. Damit konnte man OpenAL in Wine in vollem Umfang nutzen, inkluse Ausgabe von Ambisonics B-Format an einen Audioserver wie Jack. Jetzt werden die OpenAL Aufrufe in Wine selbst mit dem Windows-Port der Bibliothek verarbeitet. Das hat leider zur Folge, dass man mit neueren Wine Versionen Ambisonics nicht mehr so gut nutzen kann. Von Wine aus kann derzeit maximal 5.1 an das Host-Betriebssytem übergeben werden. Konkret bedeutet das, dass man für komplexe Ambisonics Setups entweder native Linux-Ports oder ältere Wine Versionen nutzen muss (ca. vor Version 7).
 
Hier auch noch mal mein Erfahrungsbericht:

Die Höheninformation in Unreal funktioniert tatsächlich, kaum zu glauben. kA, was Smirf mit der fehlenden W-Komponente meint (dem Schalldruck bei AmbiSonics), denn es geht auch so.
Und es geht verdammt gut. Ich verwende das 3D7.1 Setup, und man kann/könnte tatsächlich die Sounds overhead um einen herum bewegen hören. Das liegt aber auch daran, dass die Interpolation zwischen Lautsprechern bei AmbiSonics (in der Version von kCat) ziemlich gut ist.

Es ist ziemlich gut, aber: Da ginge noch viel mehr, wenn man mehr Lautsprecher hätte (OpenAL-Soft unterstützt 3. Ordnung -> 3+1 hoch 2 -> 16 Lautsprecher), womit wir beim Thema wären:

Ich hab mir das auf Windows mal angesehen, und zB VST-Host von Hermann Seib genommen (Cantabile funktioniert bei mir nicht), und mal alle VST-Decoder durchprobiert, dazu Jack for Win.
Kann man mMn komplett vergessen. Selbst wenn das irgendwie doch funktionieren würde, wäre es zu aufwändig, zu umständlich, zu verkompliziert. Ist mir völlig schleierhaft, wie OpenAL einen
AmbiSonics B-Stream an Jack liefern soll, wenn Jack auf Windows nur ASIO versteht. Kann eigentlich nur via HDMI an einen Receiver gesendet werden, ansonsten sehe ich (zumindest in der Windows Version) keinen wirklichen Sinn.

Was wir wirklich bräuchten (und vielleicht kann jemand mit besserem Kontakt zu kCat das mal kommunizieren), wäre eine ASIO Implementierung in OpenAL-Soft. Dann könnte man alles mit einem einzigen Tool erledigen. Denn nur mit ASIO ist es möglich, an Windows vorbei mehr als 7.1 Lautsprecher zu adressieren. Das würde nur eine Seite mehr für's Routing bedeuten (16 Kanäle).
Besonders komfortabel wäre es natürlich, wenn man direkt in OpenAL auch entsprechende Tools hätte, um die notwendigen Berechnungen auch ohne Octave o.ä. zu vereinfachen (wurde vom Entwickler aber schon angedeutet).

Ich stelle mir eine Matrix mit 12 Lautsprechern vor, die einen Würfel nachbildet. Die acht Ecken werden direkt mit Lautsprechern besetzt, die restlichen vier Lautsprecher bilden einen Ring in Ohrhöhe, nur um 90° versetzt. Sodass die Beschallung in der wichtigeren Ohrhöhe von links/rechts und von vorne/hinten kommt. Das erscheint mir auch für die Interpolation bei AmbiSonics die ideale Aufstellung zu sein.
Wie gesagt, ich brauche auf keine Kompatibilität Rücksicht zu nehmen, weil bei mir alles ein eigenes individuelles Setting bekommt.
 
Danke für deinen Bericht. Damit bist du die erste Person, von der ich gelesen habe, dass sie eine 3D7.1 Aufstellung realisiert hat.

OpenAL Soft unterstützt in der Entwicklungsversion seit kurzer Zeit die Ausgabe über die Windows Spatial API. Damit müsstest du ein 7.1.4 System mit einem modernen Receiver ansprechen können. Du müsstest dir vermutlich die Dolby Access App oder DTS Sound Unbound Software installieren und einrichten sowie in der alsoft.ini diese Option setzen:
Code:
[wasapi]
spatial-api = true

Der Würfel mit 12 Lautsprechern klingt interessant. Allerdings wirst du ausprobieren müssen, ob das wirklich so gut funktioniert, wie man denken könnte. Generell wird zwischen zwei Lautsprechern etwa ein 60° horizontaler Winkel für ein lückenloses Panning empfohlen. Bei dem Würfel hättest du 90° in der Horizontalen. Alternativ könntest du über zwei Ebenen bestehend aus Hexagons nachdenken. Wenn du allerdings auch von unten etwas hören wolltest, wäre ein Würfel sicherlich eine ökonomische Lösung.
 

Ähnliche Themen

Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh