GS_Audio

1 - Audio Signal Model

This page is the model every other audio page assumes. It describes how sound is put together in GS_Play — what processes audio, what merely computes numbers, the order stages run in, and the words used for each part.

Read it before the feature pages. Several parts of the audio API look arbitrary until you know the model, and one of them (spatialization) is deliberately not where most engines put it.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• Two Planes
• What Each Library Does
• The Canonical Chain
• Vocabulary
• Spatialization
• Frame Size — the Audio Timestep
• See Also

Two Planes

Audio is two planes that meet at nodes.

The audio plane is the ground floor and the only floor that reaches the speakers. Everything audible is a node in one miniaudio graph. Fan-in sums automatically; you route by attaching one node’s output to another’s input.

The control plane never carries audio. It writes numbers that the audio plane reads — the listener transform, a source’s position, an occlusion factor, reverb decay times, a binaural direction.

Control plane writes; audio plane reads. That decoupling is what keeps the system tractable, and it is the one sentence to leave this page with.

What Each Library Does

Three libraries are involved, and they are not peers. Confusing their roles is the most common way to misread the system.

The rule: anything that makes sound becomes, or feeds, a miniaudio node. SoLoud and Steam Audio both relay into miniaudio; neither bypasses it.

SoLoud ships in the base gem. The framework’s own effect and source nodes were extracted into a header-only layer so they can be wired directly into the miniaudio graph, but they remain derivative of SoLoud and are sourced from it — the attribution belongs to the free tier, not only to Pro. Pro then uses SoLoud further as the synthesis engine behind Klatt voice.

Steam Audio is worth stating twice, because it is the one people misplace. Its simulation is a parallel world you connect into. It produces numbers. Nodes consume those numbers. miniaudio moves the audio.

The Canonical Chain

Every sound travels the same path from emission to speakers:

Emission          Source + local tone shaping (EQ, filters, per-emitter mix nodes)
    |
    v
Environment       Manual Reverb  XOR  Steam reflections/occlusion   <-- SAME layer
    |
    v
Binaural / HRTF   the "ears" stage — ALWAYS LAST before volume, if spatial
    |
    v
Volume Channel    grouped, options-driven gain
    |
    v
Master  ->  speakers

Two rules hold everywhere:

Manual reverb and Steam reflections are the same conceptual layer — the environment. Manual reverb fakes the room. Steam reflections are the room, derived from real geometry. Use one or the other. Stacking them double-reverbs the sound.

Binaural/HRTF is always the last stage before the volume channel. It is the ears. Nothing spatial happens after it.

Worked cases:

Vocabulary

The audio docs use these four words precisely. Source → Spatialization → Volume Channel → Master.

Spatialization and volume channels are orthogonal. A voice line, a footstep and a magic blast all get position-based spatialization, and all three route to different volume channels. One is about where the sound is; the other is about what kind of sound it is.

Spatialization

Most audio middleware lets you drop a spatializer into an effects chain. GS does not. Spatialization is a property of the source, and the framework applies it for you.

Where it happens. Each 3D sound instance gets its own spatializer node, placed between the source and its volume channel — the Binaural stage in the chain above. It is always the last thing before volume.

One spatializer, never two. A 3D source is spatialized by either miniaudio’s built-in spatializer or Steam Audio’s binaural path, decided by the project’s spatialization mode on the Audio Manager. The two are alternatives. They are never stacked, because a fixed HRTF layered over a positional pan cancels the spatial presence the pan was already producing.

It is applied procedurally. You do not author it per sound. The framework inserts the node, recomputes direction each frame from the source-to-listener vector on the control plane, and handles distance attenuation alongside it. Every 3D source therefore behaves the same way, whether it came from an event, a graph or a voice — consistent and reliable, with nothing to wire up and nothing to get wrong.

Channel discipline is why the position is fixed. Binaural is mono- or stereo-in and always stereo-out, so it has to sit at a defined point in the chain rather than anywhere a designer drops it.

Frame Size — the Audio Timestep

Steam Audio effects want exactly one block of samples per call. A mismatch is audible as crunching.

The framework therefore treats frame size as a fixed audio timestep. By default it queries the miniaudio device period and matches it, rather than adapting with a ring buffer. This is exposed on the Audio Manager as Auto (recommended) versus Fixed.

Think of it the way you think of a physics timestep: a rate the whole simulation agrees on, not a per-effect setting.

See Also

For the systems this model describes:

• Audio Manager — the listener, project settings, and the engine
• Mixing & Effects — the Emission and Volume Channel stages
• GS_Options — what drives volume channel levels

For conceptual overviews and usage guides:

• The Basics: GS_Audio

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

2 - Audio Manager

Base — ships in GS_Audio.

The Audio Manager is the singleton that owns the audio system. It initializes the engine, builds the mixing channel graph, loads your event libraries, and carries the listener that all spatialization is measured against.

It extends GS_ManagerComponent, so it participates in the standard manager lifecycle — including headless deployment if your project has no Game Manager. Like every manager it responds to standby, pausing audio while a blocking operation such as a stage change completes.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• What It Owns
• The Listener
• Project Settings
• API Reference
• Extending with GS_AudioPro
• See Also

What It Owns

• The miniaudio engine, node graph and output endpoint.
• The named set of mixing channels.
• The loaded .aev event libraries.
• The authoritative listener.
• The shared Steam Audio context and HRTF used for spatialization.
• The mix effect registry and its deferred routing.

The base manager does not tick. Per-frame work belongs to the systems that need it.

The Listener

There is no separate listener component. The manager carries the listener, and you point it at an entity. One listener, unambiguous.

Splitting the listener for third-person

The split targets exist for third-person games, and they are the recommended setup for one.

In third person, the camera and the character are in different places, and the two halves of “where is the listener” want different answers. Proximity should follow the character — how close a sound is to you is about your body, not your camera. Direction should follow the camera — what is on your left is about where you are looking.

Set them separately and the manager switches to computing both, which is what produces the result the framework was tuned for. Set only SetListener and both follow one entity, which is correct for first-person.

Project Settings

GS_AudioProjectSettings is a reflected block on the manager, so the component panel is the configuration UI. TypeId {2B7F4C19-8E63-4A05-9D2C-6F1A8B3E7D40}.

HRTF settings are hidden unless spatialization is Binaural; the fixed frame size is hidden unless the mode is Fixed.

Geometry settings are not here — they are additive on the Pro manager, and the base gem never reflects them.

API Reference

Request Bus: AudioManagerRequestBus

Singleton bus — single address, single handler. Call via Broadcast.

Libraries and playback

Volume and channels

These are the natural attachment point for the options system’s audio sliders.

Environmental influence

See Mixing & Effects for how influences stack.

Mix effect routing

Runtime control of named mix effect chains — RerouteMixEffect, SetMixEffectParam, SetMixEffectParamOn and the registration and wiring calls. Documented in full on the Mix Effects page.

Listener

The seven listener methods are tabled under The Listener.

Extending with GS_AudioPro

Worth understanding even if you never write a gem against it, because it is a clean example of how GS gems layer.

GS_AudioPro does not subclass the base manager’s internals or reach into its private state. It fetches primitives across a small accessor surface and attaches its own nodes to them:

Two accessors run the other way and are null in a base-only install — this is how the base gem stays standalone while Pro enriches it:

The interface those two are typed against is declared in the base gem and implemented in Pro. That is the entire enrichment mechanism: base defines the socket, Pro supplies the plug, and nothing breaks when the plug is absent.

The Pro manager subclasses the base one and declares itself incompatible with it, so the two cannot coexist on an entity. A project running Pro puts the Pro manager component on its manager prefab in place of the base one, and authors everything — channels, libraries, project settings — on that single component.

See Also

For related systems:

• Audio Events — what the libraries contain
• Mixing & Effects — the channels this manager owns
• Spatialization — what the listener feeds
• Manager (Base) — the lifecycle it participates in

For conceptual overviews and usage guides:

• The Basics: Audio Manager

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

3 - Audio Events

Base — ships in GS_Audio.

An audio event is a named sound the game can fire. Events live in .aev event libraries, which are loaded onto the Audio Manager; firing one is a matter of naming it.

The important structural fact: an event declares only what plays. Everything else — pooling, concurrency limits, distance falloff, 3D tracking, spatialization, re-fire suppression — is shared machinery that every event type inherits. That is what makes adding a new kind of sound source cheap.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• Event Libraries
• Event Types
• Shared Configuration
• Firing Events
• Instancing and Pooling
• Spatialization
• Writing a New Event Type
• See Also

Event Libraries

AudioEventLibrary

A loadable collection of events, authored in the Asset Editor.

Libraries are assigned to the Audio Manager and can also be added or removed at runtime:

Both are on AudioManagerRequestBus.

Event Types

GS_AudioEvent is an abstract base, and a library holds AZStd::vector<GS_AudioEvent*>. When you add an event in the Asset Editor, the type dropdown offers every registered subtype.

This is the framework’s standard polymorphic array authoring shape: a raw-pointer vector of a reflected abstract base, where the serializer supplies the type picker and the owning container owns its elements.

The pooling model is the reason to prefer pools over single assets. Five mutated explosion profiles in one Sfxr event, or five recorded footstep variants in one Pool event, means the sound never repeats identically — with no logic on the calling side.

Shared Configuration

Every event type carries these, regardless of what produces its sound.

Firing Events

All three are on AudioManagerRequestBus, and all three resolve the event by name across every loaded library.

Instancing and Pooling

Each event owns a flat pool of voices, and the model is identical across every event type.

• A fire takes an idle voice from the pool, or produces one if none is free.
• Active, paused and tracking sets are maintained per event. The tracking set maps a voice to the entity it follows for 3D updates.
• The pool is trimmed on an interval — by default every 10 seconds — so a burst of sound does not permanently inflate memory.
• The concurrency limit is enforced per event, so one over-eager emitter cannot flood the mixer.

Routing survives late changes. When a mix effect registers after an event has already preloaded, the manager re-points every pooled and future instance at the new target. In practice this means you can add a MixEffectComponent at runtime and voices that were already pooled will follow it — you are not required to have the routing in place before sounds exist.

Spatialization

Resolved once at preload; the project’s spatialization mode does not change at runtime.

When binaural is active, a 3D voice routes through its own Steam Audio binaural node instead of miniaudio’s spatializer, and the event pushes the listener transform as it ticks. The shared Steam Audio context and HRTF are borrowed from the Audio Manager rather than created per event.

See Spatialization for the behaviour, and the Audio Signal Model for why this is a property of the source rather than an effect.

Writing a New Event Type

Subclass GS_AudioEvent and implement a small set of virtuals. Everything in Shared Configuration, Instancing and Pooling and Spatialization is inherited.

The four optional hooks exist for asset-backed sources. A generator — noise, sfxr, or anything you synthesise — leaves them as no-ops and is simply ready once the engine exists. The asset machinery is optional, not assumed.

Reflect your subclass and it appears in the event type dropdown automatically. There is no registry to add it to.

See Also

For related systems:

• Audio Manager — loads libraries and owns the listener
• SFXR Profiles — what the Sfxr event type consumes
• Mixing & Effects — where an event’s mixing channel routes to
• Audio Signal Model — how a fired event reaches the speakers

For conceptual overviews and usage guides:

• The Basics: Audio Events

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

4 - SFXR Profiles

Base — ships in GS_Audio.

.sfxrprofile assets are procedural sound effects built on the DrPetter sfxr model — the classic generator behind coin pickups, laser shots, jumps and explosions. Each profile is a complete sound described entirely by parameters, so it takes no audio files and no disk space worth measuring.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• The Model
• Importing from sfxr.me
• Profile Pools
• Shipped Profiles
• See Also

The Model

One .sfxrprofile is one sound, stored as an explicit parameter set.

There is deliberately no preset enum and no preset-plus-seed mode. The canonical sfxr presets were baked out into asset files instead of kept as a runtime option, so every sound in a project is inspectable and editable the same way — including the ones that came with the gem.

SfxrParamSet carries 24 parameters: the wave type plus 23 floats covering envelope, frequency, vibrato, arpeggio, duty cycle, retrigger, phaser, filters and volume.

The field layout matches the sfxr.me / jsfxr Serialize JSON field for field, which is what makes the import below a straight paste.

Three sfxr parameters are not stored — master volume, vibrato delay, and the filter enable flag — because jsfxr does not export them. The runtime supplies sfxr’s defaults for all three.

Importing from sfxr.me

The asset carries an Import from sfxr.me group with a multi-line paste field.

1. Design your sound at sfxr.me or any jsfxr-based tool.
2. Press Serialize and copy the JSON.
3. Paste it into the import field on the profile asset.
4. The parameters populate on change. Save the asset.

This is the recommended authoring loop: the browser tool has instant preview and randomize/mutate buttons, and the result lands in your project in one paste.

Three things to know:

• If the pasted JSON reports oldParams: false, a warning is emitted. Sfxr.me emits true, which is what the framework’s parameter model matches.
• The inspector may need a reselect to repaint after a paste. The values are imported correctly — this is a display refresh issue, not an import failure.
• Wave Type is authored as a spin box over 0-3 rather than a named dropdown, because the underlying field is a plain integer.

Profile Pools

Profiles are consumed as pools, not one at a time. Both consumers hold a vector of profile assets and pick one at random per fire:

An empty pool is silent — the event reports that it has no content. A single profile is just a pool of one.

The authoring idiom this enables is the point of the whole system: generate five mutated explosions and drop them all in one pool, and the explosion never sounds identical twice. Mutation is a single button in sfxr.me, so building the pool costs about a minute.

Shipped Profiles

GS_Audio ships 27 profiles in Assets/SFXR Profiles/:

• 7 canonical presets — Coin, Laser, Explosion, Powerup, Hurt, Jump, Blip.
• 20 named custom profiles.

These are free-tier gem content. A new project has working sound effects before it has any audio assets of its own.

See Also

For related systems:

• Audio Events — the Sfxr event type
• Audio Event Graph — the Sfxr node (Pro)

For conceptual overviews and usage guides:

• The Basics: SFXR Profiles

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

5 - Mixing & Effects

Base — ships in GS_Audio.

Mixing has two parts, and it is worth separating them from the start.

Volume channels are the grouping layer — voice, environment, combat SFX — each with its own level, feeding Master. This is the layer your options menu drives.

Mix effects are the processing layer — filters, EQ, delay, reverb, character effects — authored as named chains on components and routed by name. This is the free tier’s authoring surface for the DSP palette, and it is not a reduced one: it exposes the same 22 processors that Audio Pro exposes as graph nodes.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• Volume Channels
• Environmental Influence
• Mix Effects
• API Reference
• Data Structures
• See Also

Volume Channels

GS_MixingBus

A custom miniaudio node that mixes its inputs, applies a level, and optionally runs an effects chain.

The Audio Manager owns a named set of these. GetMixingChannelNames enumerates them and ChangeChannelVolume sets a level.

This is the Volume Channel stage of the canonical signal chain: grouped sound types feeding Master. It is orthogonal to spatialization — a voice line, a footstep and a spell all get positional audio, and all three route to different channels.

Channels are the natural attachment point for the options system’s audio sliders, which is exactly what the shipped audio apply targets do.

Environmental Influence

An entity in the world can temporarily impose an effect set on channels — walk into a cave and everything gains reverb; walk out and it lifts.

Influences stack by priority and are keyed by the entity that applied them, so removal is unambiguous even when several influences overlap. Two overlapping zones resolve by priority rather than by whichever fired last.

Mix Effects

The processing layer. A MixEffectComponent holds an ordered chain of effects, registers it under a name, and feeds its output somewhere — another chain, or a volume channel. Sources route in by naming that chain as their mixing channel.

Twenty-two effect types are available, in four families: biquad filters, time and space, character and modulation, and utility.

Mix Effects API

API Reference

Request Bus: GS_MixingRequestBus

Channel control. Singleton bus — single address, single handler.

Master and per-channel volume are also reachable from AudioManagerRequestBus via ChangeMasterVolume and ChangeChannelVolume.

Data Structures

See Also

For related systems:

• Mix Effects — the 22 effect types and the component that chains them
• Audio Manager — owns the channel set
• Audio Events — an event’s mixing channel selects a target here
• Audio Signal Model — where this layer sits
• GS_Options — drives channel levels from player settings

For conceptual overviews and usage guides:

• The Basics: Mixing & Effects

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

5.1 - Mix Effects

Base — ships in GS_Audio.

Mix effects are the DSP processing layer of the free tier. You build a chain of effects on a component, give it a name, and point sources at that name.

Twenty-two effects are available. They are the same processors Audio Pro exposes as graph nodes — one processor, two authoring surfaces. Choosing the free tier does not reduce what you can do to a signal; it changes how you author it.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• MixEffectComponent
• How Chains Route
• The 22 Effects
• Runtime Control
• Two Cautions
• See Also

MixEffectComponent

Drop it on an entity and it holds an ordered chain of effects — a polymorphic list where each entry’s concrete type is chosen from a dropdown.

The chain runs top to bottom. Index 0 is what gets registered under Name; the last entry feeds Output Target.

Setup is idempotent, and teardown unwires and destroys the nodes while keeping the authored list — so the component re-activates cleanly.

How Chains Route

Sources route in by name. An audio event’s Mixing Channel field can name either a volume channel or a mix effect chain. They share one namespace, so a source does not need to know which kind of thing it is pointing at.

Any number of chains can live on one entity, each with its own Name. Point one chain’s Output Target at another chain’s Name to compose them.

Wiring is order-independent. If a chain’s target does not exist yet, the connection is deferred and resolves when the target registers. You do not have to think about component activation order, and a missing target is not an error — it is a connection waiting to be made.

Routing catches up with sounds that already exist. When a chain registers after events have preloaded, already-pooled voices are re-pointed at the new target. Adding a MixEffectComponent at runtime works, and the sounds that were already playing through that channel follow it.

Local and global routing

Both patterns are supported and they coexist:

• Global named channels — everything funnels through shared, named mix targets. Best for project-wide treatments.
• Local chains on the emitting entity — the component lives on the emitter, scoping its effects to that one emission. Best for per-character or per-object colour.

The 22 Effects

Biquad filters

Time and space

Character and modulation

Utility

Runtime Control

Chains are drivable at runtime through AudioManagerRequestBus, so ScriptCanvas can change a treatment while it is playing.

Environmental treatment is per-emission and rapidly modifiable by design. A character moving through a space changes its effects continuously, and that change isolates to the environmental portion of the signal regardless of which volume channel the sound belongs to.

Two Cautions

See Also

For related systems:

• Mixing & Effects — volume channels and environmental influence
• Audio Events — how a source selects a chain
• Spatialization — the automatic per-source path
• Audio Signal Model — where processing sits in the chain

For conceptual overviews and usage guides:

• The Basics: Mixing & Effects

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

6 - Spatialization

Base — ships in GS_Audio.

Spatialization is what makes a sound feel like it is coming from somewhere. In GS_Audio it is powered by Steam Audio and it is automatic: place a source in the world and it is spatialized, with no per-sound setup and nothing to wire into an effects chain.

This page covers what the base gem does. Occlusion and geometry-driven reflections — sound genuinely blocked and reverberated by world geometry — are Audio Pro features.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• How a Sound Is Placed
• Distance
• Configuration
• Limits Worth Knowing
• See Also

How a Sound Is Placed

Each 3D sound instance gets its own spatializer node, inserted between the source and its volume channel. Direction is recomputed every frame from the source-to-listener vector.

A source uses either miniaudio’s built-in spatializer or Steam Audio’s binaural path, depending on the project’s spatialization mode. Never both — a fixed HRTF layered over a positional pan cancels the spatial presence the pan was already producing.

The listener that all of this measures against lives on the Audio Manager, including the split spatial/orientation setup that lets proximity follow your character while direction follows your camera.

See the Audio Signal Model for where this sits in the chain and why it is a property of the source rather than an effect.

Distance

Distance is handled alongside direction: attenuation plus air absorption, both derived from the source-to-listener distance and the event’s authored Distance Min/Max.

The framework uses a bounded distance curve rather than the raw inverse-distance model:

The reason to state this plainly: a pure inverse-distance model never reaches zero and ignores a maximum distance, which leaves a faint version of every sound audible forever. The bounded curve trades physical exactness for a max distance that actually means something. An event’s Distance Min/Max therefore controls both how far the dry sound carries and how far it feeds the environment.

It is a chosen curve, not a physical simulation.

Configuration

All of it lives on the Audio Manager’s project settings, so the manager’s component panel is the configuration surface.

HRTF settings are hidden in the editor unless spatialization is set to Binaural.

The spatialization back-end is resolved when sounds preload and does not change at runtime.

Limits Worth Knowing

These are expected behaviour for the technique, not defects — worth knowing before you evaluate the result.

• Front/back and elevation cues are subtle. The HRTF is generic, with no head tracking and no per-listener personalization. Left/right positioning is clear and reliable; “above and behind me” is not something a generic HRTF conveys strongly.
• Distance attenuation is a chosen curve, as described above, rather than physically exact falloff.
• Nothing blocks sound in the base gem. A sound behind a wall is quieter with distance but is not occluded — geometry is not consulted. Occlusion and geometry-driven reverb are Audio Pro features.

See Also

For related systems:

• Audio Manager — the listener and project settings
• Audio Events — per-event distance and 2D/3D
• Audio Signal Model — where spatialization sits in the chain

For conceptual overviews and usage guides:

• The Basics: Spatialization

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

7 - Audio Pro

GS_AudioPro is the premium audio gem. It requires GS_Audio and extends it — every base feature keeps working exactly as documented, and Pro adds four capabilities of its own.

Contents

• How Pro Attaches to the Base Gem
• Enabling Audio Pro
• Bus Map
• Features
• See Also

How Pro Attaches to the Base Gem

GS_ProAudioManagerComponent subclasses the base Audio Manager, which in turn subclasses GS_ManagerComponent. It declares itself incompatible with the base manager, so the two cannot coexist on one entity — a project runs one or the other.

Pro never reaches into the base gem’s internals. It fetches primitives across the accessor seam — the engine, the node graph, the output endpoint, volume channels, the shared Steam Audio context — and attaches its own nodes to them.

Two accessors run the other way, and they are the whole enrichment mechanism:

• Pro registers its spatial simulator, and the base gem’s per-voice spatializer starts consuming occlusion values from it.
• Pro exposes a reverb send, and base voices tap into it to feed geometry-driven reverb.

Both are null in a base-only install. The interface they are typed against is declared in the base gem and implemented in Pro — base defines the socket, Pro supplies the plug, and nothing breaks when the plug is absent.

Configuration follows the same shape. The base project settings stay where they are; Pro adds its geometry settings additively on the Pro manager. The base gem never reflects Pro’s knobs.

Enabling Audio Pro

1. Enable the GS_AudioPro gem alongside GS_Audio.
2. Put the Pro Audio Manager component on your manager prefab in place of the base one.
3. Assign your graph libraries and score tracks on that component.

Everything the base manager configures — volume channels, event libraries, project settings — is authored on the Pro component too, since it inherits them. Pro’s geometry settings appear alongside them.

A project runs one manager or the other; the two cannot coexist on an entity.

Bus Map

In ScriptCanvas, Pro’s nodes sit under the GS_Play/GS_AudioPro category, with each bus grouped under its own feature name. Base nodes remain under GS_Play/GS_Audio.

Features

Audio Event Graph

Build a sound as a node graph — sources, filters, effects and conditional routing on a canvas, with a Start / Loop / Finish phase lifecycle and runtime variables that reshape the sound while it plays. The same DSP processors the base gem exposes as mix effects appear here as nodes.

Audio Event Graph

Score Arrangement

Multi-layer music assets. An arrangement defines time signature, tempo and fade behaviour and holds layers that can be brought in and out independently, so the score follows game state instead of looping past it.

Score Arrangement

Klatt Voice Synthesis

Formant text-to-speech with 3D spatial audio. It generates voice from parameters rather than playing recordings, so a project can give hundreds of characters distinct voices with no audio assets and no recording sessions.

Klatt Voice

Geometric Acoustics

Sound occluded by the geometry between it and the listener, and reverb derived from the room the listener is actually standing in — driven by authored acoustic volumes and O3DE shapes with material presets.

Geometric Acoustics

See Also

For the base gem this builds on:

• GS_Audio — the free tier
• Audio Manager — including the accessor seam Pro attaches through
• Audio Signal Model — where each Pro feature sits in the chain

For conceptual overviews and usage guides:

• The Basics: Audio Pro

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

7.1 - Audio Event Graph

The Audio Event Graph is an FMOD-style visual editor for authoring complex sound events. Each .audiograph file defines one sound event as a node graph — sources, filters, effects, and routing all connected visually. At runtime, the graph maps directly to a miniaudio processing pipeline.

The Audio Event Graph uses the gs_graphcanvas framework with a DataFlowGraph topology. Nodes evaluate in topological order with dirty-propagation — only nodes affected by a change are re-evaluated.

Contents

• Opening the Editor
• How It Works
• Node Catalog
• Phase Lifecycle
• Using Variables
• Extending with Custom Nodes
• Runtime API
• See Also

Opening the Editor

Open the Audio Event Graph editor from the O3DE Editor menu: GS Tools > Audio Event Graph Editor.

Each graph is a standalone .audiograph file — use File > New to create one, or File > Open to load an existing graph. Multiple graphs can be open simultaneously in separate tabs.

How It Works

Audio Event Graphs use a data-flow model. Connections carry AudioRoute values — handles that represent a point in the miniaudio processing chain. The signal flows left to right:

1. Entry nodes gate which phase is active (Start, Loop, or Finish)
2. Source nodes create sound instances and output an AudioRoute
3. Filter and effect nodes process the audio and pass it along
4. Routing nodes (If/Switch) direct the signal based on conditions or variables
5. The Output node wires the final AudioRoute to a mixing bus

Variables can be set from gameplay code at any time, causing affected nodes to re-evaluate without restarting the entire graph.

Node Catalog

Entry Nodes (Phase Gates)

Entry nodes output a gate signal. Downstream nodes only produce audio when their entry gate is active.

Source Nodes

Filter Nodes

All filter nodes take an audio_in input and produce an audio_out output. Filter parameters (cutoff frequency, Q factor, gain) are configurable per-node or bindable to variables.

Time & Space Nodes

Character & Modulation Nodes

Utility Nodes

These are the same processors the base gem exposes as mix effects — one DSP, two authoring surfaces. Two mix effects have no node form: Binaural, because spatialization is automatic and per-source, and Pitch.

Structure Nodes

Routing Nodes

The built-in gs_graphcanvas IfNode and SwitchNode work with AudioRoute values. Use them for conditional audio paths based on game state variables (e.g., play different sounds based on surface type or weather).

Terminal Node

Every graph needs exactly one Output node.

Phase Lifecycle

Audio Event Graphs support a three-phase lifecycle for structured sound playback:

1. Start — Initial playback. The Aud_StartNode gate is active. One-shot intro sounds play here.
2. Loop — Repeating section. The Aud_LoopNode gate is active. Ambient loops and sustained sounds live here.
3. Finish — Outro/tail. The Aud_FinishNode gate is active. Fade-outs and release tails play here.

Phases transition automatically: Start plays once, then Loop repeats (if looping is enabled), then Finish plays when FinishAudioGraph() is called. Not all phases are required — a simple one-shot sound only needs a Start node.

Using Variables

Variables let gameplay code control sound behavior at runtime. Common uses:

• Filter parameters — Bind a filter’s cutoff frequency to a variable, then adjust it from code (e.g., underwater muffling)
• Routing conditions — Use a variable as the condition for an If/Switch node to select different sound paths
• Source selection — Gate different source nodes based on game state

Declare variables in the Variable Panel, then either bind them to input slots (right-click > Convert to Reference) or use Get/Set variable nodes.

At runtime, set variables via the Audio Manager API:

AudioManagerRequestBus::Broadcast(&AudioManagerRequests::SetAudioGraphVariable, instanceId, "underwater", 0.8f);

Setting a variable marks dependent nodes dirty and re-evaluates only the affected portion of the graph.

Extending with Custom Nodes

To add a custom audio node:

1. Create a class inheriting from BaseNode and IDataFlowNode
2. Register it with GS_AUTO_REGISTER_NODE_FOR(MyAudioNode, "audiograph")
3. Implement Process(GraphExecutionContext& context)
4. Follow the empty any pattern for inactive outputs:

void MyAudioNode::Process(GraphExecutionContext& context)
{
    auto inputAny = context.GetInputValueAny(this, "audio_in");
    if (inputAny.empty())
    {
        context.SetOutputValueAny(this, "audio_out", AZStd::any{});  // CRITICAL: truly empty
        return;
    }
    // Process audio...
    context.SetOutputValue(this, "audio_out", outputRoute);
}

The empty any pattern ensures that inactive paths don’t mask valid audio from other connections in multi-input slots.

For full details on node creation, see gs_graphcanvas Nodes.

Playing a Graph

There are three ways to reach a graph. They form an escalation ladder — most projects should use the last one.

AudioGraphPlayerComponent

The recommended surface. Drop it on an entity, point it at a graph, and it handles the rest.

It acquires lazily on the first Play or variable set, applies spatialization and looping, and holds its own handle — there is no acquire/release to write. Its per-entity bus offers Play, Finish, Stop, and SetVariable in float, int, bool and string forms.

With no Pro manager present it is inert and warns rather than failing.

Graph libraries

An AudioGraphLibrary (.agl) maps names to graphs, so gameplay code refers to "door_creak" rather than a path. Libraries are assigned to the Pro manager and can be added or removed at runtime.

Because .audiograph is a source-only file — no builder, no product asset — the library uses a custom picker that browses source files directly rather than the product catalog. This is the same approach ScriptCanvas uses for .scriptcanvas, and it is worth copying if you build an asset that references source files.

Current limitation: the picker stores an absolute source path.

Instance Lifecycle

This is the behaviour most likely to surprise you, so it is worth stating plainly.

There are two kinds of instance:

• Fire-and-forget — created by PlayGraph / PlayAudioGraph, destroyed when it stops.
• Owned — created by AcquireGraph / AcquireAudioGraph, and kept until you explicitly release it.

For an owned instance, Stop, Finish, a fade-out or a natural end all quiesce it to idle rather than destroying it. Sounds stop, pooled resources return, entry gates deactivate and the phase resets — but the instance, its variables and its spatial and loop configuration are all retained. Only ReleaseAudioGraph or manager shutdown actually destroys it.

The reason: a play → loop → end → replay cycle should keep its variables across calls. What you hear is identical to destruction; the difference is that replaying does not mean reconfiguring.

GetGraph(name) returns the live instance for a name, acquiring on first call. Repeat calls return the same id, and because owned instances persist, a handle normally stays valid for the lifetime of whatever is holding it.

All instance ids are 64-bit unsigned integers, and 0 means failure.

Runtime API

Everything below is on AudioGraphRequestBus — a GS_AudioPro bus, not the Audio Manager’s.

Named access: AddGraphLibrary, RemoveGraphLibrary, PlayGraph(name), AcquireGraph(name), GetGraph(name)

Raw path: PlayAudioGraph(assetPath), AcquireAudioGraph(assetPath)

Transport: FireAudioGraph(id), StopAudioGraph(id), StopAllAudioGraphs(), FinishAudioGraph(id), StopAudioGraphFade(id, fadeTime), ReleaseAudioGraph(id)

Variables: SetAudioGraphVariable (float), SetAudioGraphVariableInt, SetAudioGraphVariableBool, SetAudioGraphVariableString — each taking (instanceId, name, value)

Spatialization: SetAudioGraphEntity(id, entity), SetAudioGraphPosition(id, position), ClearAudioGraphSpatialization(id)

State: SetAudioGraphLooping(id, bool), IsAudioGraphActive(id)

Per-entity playback goes through AudioGraphPlayerRequestBus instead, addressed by entity id.

See Also

• Audio Pro — the rest of the premium tier, and the full bus map
• gs_graphcanvas Framework — the underlying framework
• Mix Effects — the same processors, authored on components
• Audio Events — simple event-based playback, in the free gem
• SFXR Profiles — what the Sfxr node consumes

7.2 - Score Arrangement

The Score Arrangement system provides multi-layer dynamic music for GS_Play projects. A ScoreArrangementTrack asset defines a musical score with configurable tempo, time signature, fade behavior, and multiple layers that can be enabled or disabled at runtime. This allows game music to adapt to gameplay state – adding or removing instrumental layers, changing intensity, or crossfading between sections.

Score tracks are assigned to the Pro Audio Manager and controlled through AudioScoreRequestBus. They are not on the base audio manager’s bus.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• Data Model
• API Reference
• See Also

Data Model

ScoreArrangementTrack

A multi-layer musical score asset. Each track defines the musical structure and contains one or more layers that play simultaneously.

ScoreLayer

A single musical layer within a score arrangement. Each layer represents one track of audio (e.g. drums, bass, melody) that can be independently enabled or disabled.

TimeSignatures (Enum)

Supported musical time signatures for score arrangement tracks.

API Reference

Request Bus: AudioScoreRequestBus

Singleton bus – single address, single handler. Implemented by the Pro Audio Manager.

The adaptive-music loop is PlayScore once, then PlayTrack and StopTrack as game state changes. Layers stay in time with each other because they share the arrangement’s tempo and time signature – bringing a percussion layer in mid-bar does not knock it out of sync.

See Also

For conceptual overviews and usage guides:

• GS_Audio Overview – Top-level audio gem documentation
• The Basics: GS_Audio – Scripting-level usage guide

For component references:

• Audio Manager – Controls score playback via the request bus

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

7.3 - Geometric Acoustics

The base gem places sounds by direction and distance. Geometric acoustics adds the room: sound muffled by the geometry between it and the listener, and reverb derived from the space the listener is actually standing in rather than an effect an author dialled in.

Geometry is authored, not inferred. You mark up the acoustically significant parts of a level with volumes and shapes carrying material presets — you do not hand the simulation your render meshes.

Contents

• Turning It On
• Authoring Geometry
• Acoustic Materials
• Occlusion
• Reflections
• How It Stays Safe
• What This Does Not Do
• See Also

Turning It On

Geometric acoustics is off by default. It is enabled on the Pro manager’s settings, which are additive to the base project settings.

Authoring Geometry

Two components mark up a level. Both carry a material preset, plus a custom material for the Custom case.

The Shape variant is usually the faster path — a wall you have already blocked out with a Shape becomes acoustically real by adding one component.

Registration goes through a request bus that takes raw vertices rather than entities. That is deliberate: it is what will let streaming systems fold geometry in and out of the simulation without the acoustics layer knowing anything about entity lifetimes.

Acoustic Materials

Fifteen presets, plus Custom.

The soft-barrier group is the interesting one for designers. A curtain over a doorway does not block the sound behind it, it dulls it — which is the effect people usually reach for a low-pass filter to fake.

Occlusion

Each voice is simulated against the geometry between it and the listener, and muffled accordingly.

Volumetric is what gives partial occlusion at edges — a sound leaking around a doorframe rather than switching off as it passes behind the jamb. If occlusion feels binary and abrupt, this is the setting to change.

Occlusion ducks the direct signal.

Reflections

Reverb is derived from the geometry around the listener — one shared room, recomputed as the listener moves through the level. Reflection Mode has a PerSource value reserved for future work; it currently falls back to Listener.

Two behaviours are worth understanding because they are deliberate design choices, not side effects:

Reverb eases between rooms. Crossing a geometry boundary blends the reverb toward the new room over the Reflection Smooth Time rather than snapping. Set it to 0 if you want an instant change.

Reverb does not fade with distance. Each voice taps its raw source into a wet-only reverb, so the room stays constant across its whole volume while only the dry signal falls off with distance. This is what makes a large room sound like the same room from either end of it. The reverb send does taper at the far edge of a sound’s range — flat until three quarters of max distance, then eased to zero — so an event’s distance settings still bound how far it feeds the room.

How It Stays Safe

Worth knowing if you are budgeting for this system.

Reflections use a parametric reverb model — a handful of decay-time floats — rather than convolution. No impulse response ever crosses to the audio thread, and there is no ambisonic decode in the path.

The reflection simulation runs on a worker thread at up to 15 Hz, committing its results under a mutex. Occlusion and direct-path values are lock-free single-writer floats. Everything else stays on the main thread.

The practical consequence: enabling geometric acoustics adds a bounded, predictable cost rather than a per-sound one that scales alarmingly.

What This Does Not Do

State these to yourself before evaluating the result — each is a deliberate v1 boundary, not a defect.

• Reverb cannot tell your room from the one next door. It is listener-centric, so a source sealed in an adjacent room still contributes to the same shared reverb. Distinguishing them is what per-source reflections would do, and that is not built.
• An occluded source still feeds the room. Occlusion ducks the direct signal only. Within max distance, a muffled source still excites the reverb.
• Geometry is what you author. Render meshes and PhysX colliders are not consulted — v1 is authored volumes and O3DE Shapes.
• No offline baking. There are no precomputed reverb probes.
• Reverb is the tail, not early reflections. The parametric model gives you the decay, not discrete early reflections.
• CPU only. There is no GPU acceleration path.

See Also

For related systems:

• Spatialization — the base direction and distance layer this builds on
• Mixing & Effects — influence-driven reverb, the manual alternative
• Audio Pro — the rest of the premium tier
• Audio Signal Model — why environment and reverb are one layer

For conceptual overviews and usage guides:

• The Basics: Audio Pro

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

7.4 - Klatt Voice Synthesis

The Klatt Voice Synthesis system provides custom text-to-speech using Klatt formant synthesis with full 3D spatial audio. Speech is generated by SoLoud and relayed into the miniaudio graph through a custom node, so it travels the same signal chain as every other sound – see the Audio Signal Model.

All types on this page are in the GS_AudioPro namespace.

The system has two layers:

• KlattVoiceSystemComponent – A singleton that manages the shared SoLoud engine instance and tracks the 3D audio listener position.
• KlattVoiceComponent – A per-entity component that generates speech, queues segments, applies voice profiles, and emits spatialized audio from the entity’s position.

Voice characteristics are defined through KlattVoiceProfile assets containing frequency, speed, waveform, formant, and phoneme mapping configuration. Phoneme maps convert input text to ARPABET phonemes for the Klatt synthesizer, with support for custom pronunciation overrides.

For usage guides and setup examples, see The Basics: GS_Audio.

Contents

• Components
• API Reference
• Data Types
• Enumerations
• KTT Voice Tags
• Combined Example
• See Also

Components

KlattVoiceSystemComponent

Singleton component that manages the shared SoLoud engine and 3D listener tracking.

KlattVoiceComponent

Per-entity voice component with spatial audio, phoneme mapping, and segment queue.

API Reference

Request Bus: KlattVoiceSystemRequestBus

System-level voice management. Singleton bus – Single address, single handler.

Request Bus: KlattVoiceRequestBus

Per-entity voice synthesis controls. Entity-addressed bus – Single handler per entity ID.

Notification Bus: KlattVoiceNotificationBus

Events broadcast by voice components. Multiple handler bus – any number of components can subscribe.

Data Types

KlattVoiceParams

Core voice synthesis parameters controlling the Klatt formant synthesizer output.

KlattVoiceProfile

A voice profile asset combining synthesis parameters with a phoneme mapping.

KlattVoicePreset

A preset configuration for quick voice setup.

KlattSpatialConfig

3D spatial audio configuration for voice positioning.

KlattPhonemeMap

Phoneme mapping asset for text-to-ARPABET conversion with custom overrides.

PhonemeOverride

A custom pronunciation rule that overrides the base phoneme map for a specific word or pattern.

Enumerations

KlattWaveform

Glottal waveform types available for the Klatt synthesizer.

BasePhonemeMap

Available base phoneme dictionaries for text-to-ARPABET conversion.

KTT Voice Tags

KTT (Klatt Text Tags) are inline commands embedded in strings passed to KlattVoiceComponent::SpeakText. They are parsed by KlattCommandParser::Parse and stripped from the spoken text before synthesis begins — they are never heard.

Format: <ktt attr1=value1 attr2=value2>

Multiple attributes can be combined in a single tag. Attribute names are case-insensitive. String values may optionally be wrapped in quotes. An empty value (e.g. speed=) resets that parameter to the voice profile default.

speed=X

Override the speech speed multiplier from this point forward.

Normal speech <ktt speed=2.0> fast bit <ktt speed=> back to default.

decl=X / declination=X

Pitch declination — how much pitch falls over the course of the utterance. Both decl and declination are accepted.

Rising <ktt decl=0.0> steady <ktt decl=0.8> falling voice.

waveform="TYPE"

Change the glottal waveform used by the synthesizer, setting the overall character of the voice.

<ktt waveform="noise"> whispered section <ktt waveform="saw"> normal voice.

vowel=X

First formant (F1) frequency multiplier. Shifts the quality of synthesised vowel sounds.

<ktt vowel=1.4> different vowel colour here.

accent=X

Second formant (F2) frequency multiplier. Shifts accent or dialect colouration.

<ktt accent=0.8> shifted accent here.

pitch=X

F0 pitch variance amount. Controls how much pitch varies during synthesis.

<ktt pitch=2.0> very expressive speech <ktt pitch=0.1> flat monotone.

pause=X

Insert a pause of X seconds at this position in the voice playback. Value is required — there is no default.

Hello.<ktt pause=0.8> How are you?

Combined Example

Dialogue string using typewriter text commands and KTT voice tags together:

[b]Warning:[/b] [color=#FF0000]do not[/color] proceed.[pause=1]
<ktt waveform="square" pitch=1.8>This is a mechanical override.<ktt pause=0.5><ktt waveform="saw" pitch=1.0>
[speed=3]Resuming normal protocol.[/speed]

See Also

For conceptual overviews and usage guides:

• GS_Audio Overview – Top-level audio gem documentation
• The Basics: GS_Audio – Scripting-level usage guide

For component references:

• Audio Manager – Manager lifecycle that the voice system participates in

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.

8 - Third Party Implementations

This section will contain integration guides for connecting third-party audio middleware and tools with the GS_Audio system.

For usage guides and setup examples, see The Basics: GS_Audio.

Get GS_Audio

GS_Audio — Explore this gem on the product page and add it to your project.