Hi all,
I'd like to share a proposal for a layered architecture that combines the KHR_audio_emitter and KHR_audio_graph extensions, along with a new KHR_audio_environment extension for listener
and room acoustics.
Summary
Rather than having two competing audio extensions, I propose using KHR_audio_emitter as the base layer and building graph-based processing and environmental audio on top of it:
- KHR_audio_emitter (base) — audio data, sources, emitters. One proposed change: node-level emitter (single) → emitters (array) to support multiple emitters per node.
- KHR_audio_graph (extends audio_emitter) — document-level processing graphs with explicit input/output bindings to audio_emitter sources and emitters. Includes gain, delay, 8 filter
types, waveshaper, channel routing, and graph-only oscillator sources.
- KHR_audio_environment (extends audio_emitter) — explicit listener node (HRTF/equalpower/custom), parametric and IR-based reverb, custom distance models, per-emitter spatialization
override.
Key design points
- Graphs are declared at document level with explicit bindings — not embedded in sources or emitters
- Oscillators are graph-only source nodes (no base spec change needed)
- Reverb and spatialization model selection live in the environment layer, not the processing graph
- All conventions follow audio_emitter: seconds, radians, gain (0, +∞)
- The only required change to audio_emitter is emitter → emitters (array) on node bindings
Materials
Spec proposals and gap analysis:
https://github.com/rudybear/KHR_audio_proposals
Reference implementation (Web Audio API / TypeScript):
https://github.com/rudybear/AudioGraphJS/tree/feature/layered-extensions
Includes runtime, 4 layered-format examples, browser demo, 6 test suites, and a validator. Backward compatible with existing KHR_audio_graph examples.
I welcome feedback on the approach, the spec drafts, and the proposed audio_emitter change.
Hi all,
I'd like to share a proposal for a layered architecture that combines the KHR_audio_emitter and KHR_audio_graph extensions, along with a new KHR_audio_environment extension for listener
and room acoustics.
Summary
Rather than having two competing audio extensions, I propose using KHR_audio_emitter as the base layer and building graph-based processing and environmental audio on top of it:
types, waveshaper, channel routing, and graph-only oscillator sources.
override.
Key design points
Materials
Spec proposals and gap analysis:
https://github.com/rudybear/KHR_audio_proposals
Reference implementation (Web Audio API / TypeScript):
https://github.com/rudybear/AudioGraphJS/tree/feature/layered-extensions
Includes runtime, 4 layered-format examples, browser demo, 6 test suites, and a validator. Backward compatible with existing KHR_audio_graph examples.
I welcome feedback on the approach, the spec drafts, and the proposed audio_emitter change.