Web Audio API

Abstract

This specification describes a high-level JavaScript API for processing and synthesizing audio in web applications. The primary paradigm is of an audio routing graph, where a number of AudioNode objects are connected together to define the overall audio rendering. The actual processing will primarily take place in the underlying implementation (typically optimized Assembly / C / C++ code), but direct JavaScript processing and synthesis is also supported.

The introductory section covers the motivation behind this specification.

This API is designed to be used in conjunction with other APIs and elements on the web platform, notably: XMLHttpRequest (using the responseType and response attributes). For games and interactive applications, it is anticipated to be used with the canvas 2D and WebGL 3D graphics APIs.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the fifth public Working Draft of the Web Audio API specification. It has been produced by the W3C Audio Working Group , which is part of the W3C WebApps Activity.

Please send comments about this document to <[email protected]> (public archives of the W3C audio mailing list). Web content and browser developers are encouraged to review this draft.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

2. Conformance

Everything in this specification is normative except for examples and sections marked as being informative.

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels [RFC2119].

The following conformance classes are defined by this specification:

conforming implementation

A user agent is considered to be a conforming implementation if it satisfies all of the MUST-, REQUIRED- and SHALL-level criteria in this specification that apply to implementations.

4. The Audio API

4.1. The AudioContext Interface

This interface represents a set of AudioNode objects and their connections. It allows for arbitrary routing of signals to the AudioDestinationNode (what the user ultimately hears). Nodes are created from the context and are then connected together. In most use cases, only a single AudioContext is used per document.

callback DecodeSuccessCallback = void (AudioBuffer decodedData);
callback DecodeErrorCallback = void ();

[Constructor]
interface AudioContext : EventTarget {

    readonly attribute AudioDestinationNode destination;
    readonly attribute float sampleRate;
    readonly attribute double currentTime;
    readonly attribute AudioListener listener;

    AudioBuffer createBuffer(unsigned long numberOfChannels, unsigned long length, float sampleRate);

    void decodeAudioData(ArrayBuffer audioData,
                         DecodeSuccessCallback successCallback,
                         optional DecodeErrorCallback errorCallback);


    // AudioNode creation 
    AudioBufferSourceNode createBufferSource();

    MediaElementAudioSourceNode createMediaElementSource(HTMLMediaElement mediaElement);

    MediaStreamAudioSourceNode createMediaStreamSource(MediaStream mediaStream);
    MediaStreamAudioDestinationNode createMediaStreamDestination();

    ScriptProcessorNode createScriptProcessor(optional unsigned long bufferSize = 0,
                                              optional unsigned long numberOfInputChannels = 2,
                                              optional unsigned long numberOfOutputChannels = 2);

    AnalyserNode createAnalyser();
    GainNode createGain();
    DelayNode createDelay(optional double maxDelayTime = 1.0);
    BiquadFilterNode createBiquadFilter();
    WaveShaperNode createWaveShaper();
    PannerNode createPanner();
    ConvolverNode createConvolver();

    ChannelSplitterNode createChannelSplitter(optional unsigned long numberOfOutputs = 6);
    ChannelMergerNode createChannelMerger(optional unsigned long numberOfInputs = 6);

    DynamicsCompressorNode createDynamicsCompressor();

    OscillatorNode createOscillator();
    PeriodicWave createPeriodicWave(Float32Array real, Float32Array imag);

};

4.1b. The OfflineAudioContext Interface

OfflineAudioContext is a particular type of AudioContext for rendering/mixing-down (potentially) faster than real-time. It does not render to the audio hardware, but instead renders as quickly as possible, calling a completion event handler with the result provided as an AudioBuffer.

[Constructor(unsigned long numberOfChannels, unsigned long length, float sampleRate)]
interface OfflineAudioContext : AudioContext {

    void startRendering();
    
    attribute EventHandler oncomplete;

};

interface OfflineAudioCompletionEvent : Event {

    readonly attribute AudioBuffer renderedBuffer;

};

enum ChannelCountMode {
    "max",
    "clamped-max",
    "explicit"
};

enum ChannelInterpretation {
    "speakers",
    "discrete"
};

interface AudioNode : EventTarget {

    void connect(AudioNode destination, optional unsigned long output = 0, optional unsigned long input = 0);
    void connect(AudioParam destination, optional unsigned long output = 0);
    void disconnect(optional unsigned long output = 0);

    readonly attribute AudioContext context;
    readonly attribute unsigned long numberOfInputs;
    readonly attribute unsigned long numberOfOutputs;

    // Channel up-mixing and down-mixing rules for all inputs.
    attribute unsigned long channelCount;
    attribute ChannelCountMode channelCountMode;
    attribute ChannelInterpretation channelInterpretation;

};

4.2.3. Lifetime

This section is informative.

An implementation may choose any method to avoid unnecessary resource usage and unbounded memory growth of unused/finished nodes. The following is a description to help guide the general expectation of how node lifetime would be managed.

An AudioNode will live as long as there are any references to it. There are several types of references:

1. A normal JavaScript reference obeying normal garbage collection rules.
2. A playing reference for both AudioBufferSourceNodes and OscillatorNodes. These nodes maintain a playing reference to themselves while they are currently playing.
3. A connection reference which occurs if another AudioNode is connected to it.
4. A tail-time reference which an AudioNode maintains on itself as long as it has any internal processing state which has not yet been emitted. For example, a ConvolverNode has a tail which continues to play even after receiving silent input (think about clapping your hands in a large concert hall and continuing to hear the sound reverberate throughout the hall). Some AudioNodes have this property. Please see details for specific nodes.

Any AudioNodes which are connected in a cycle and are directly or indirectly connected to the AudioDestinationNode of the AudioContext will stay alive as long as the AudioContext is alive.

When an AudioNode has no references it will be deleted. But before it is deleted, it will disconnect itself from any other AudioNodes which it is connected to. In this way it releases all connection references (3) it has to other nodes.

Regardless of any of the above references, it can be assumed that the AudioNode will be deleted when its AudioContext is deleted.

      numberOfInputs  : 1
      numberOfOutputs : 0

      channelCount = 2;
      channelCountMode = "explicit";
      channelInterpretation = "speakers";

interface AudioDestinationNode : AudioNode {

    readonly attribute unsigned long maxChannelCount;

};

interface AudioParam {

    attribute float value;
    readonly attribute float defaultValue;

    // Parameter automation. 
    void setValueAtTime(float value, double startTime);
    void linearRampToValueAtTime(float value, double endTime);
    void exponentialRampToValueAtTime(float value, double endTime);

    // Exponentially approach the target value with a rate having the given time constant. 
    void setTargetAtTime(float target, double startTime, double timeConstant);

    // Sets an array of arbitrary parameter values starting at time for the given duration. 
    // The number of values will be scaled to fit into the desired duration. 
    void setValueCurveAtTime(Float32Array values, double startTime, double duration);

    // Cancels all scheduled parameter changes with times greater than or equal to startTime. 
    void cancelScheduledValues(double startTime);

};

4.5.4. AudioParam Automation Example

Example

ECMAScript

 
var t0 = 0;
var t1 = 0.1;
var t2 = 0.2;
var t3 = 0.3;
var t4 = 0.4;
var t5 = 0.6;
var t6 = 0.7;
var t7 = 1.0;

var curveLength = 44100;
var curve = new Float32Array(curveLength);
for (var i = 0; i < curveLength; ++i)
    curve[i] = Math.sin(Math.PI * i / curveLength);

param.setValueAtTime(0.2, t0);
param.setValueAtTime(0.3, t1);
param.setValueAtTime(0.4, t2);
param.linearRampToValueAtTime(1, t3);
param.linearRampToValueAtTime(0.15, t4);
param.exponentialRampToValueAtTime(0.75, t5);
param.exponentialRampToValueAtTime(0.05, t6);
param.setValueCurveAtTime(curve, t6, t7 - t6);

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCountMode = "max";
    channelInterpretation = "speakers";

interface GainNode : AudioNode {

    readonly attribute AudioParam gain;

};

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCountMode = "max";
    channelInterpretation = "speakers";

interface DelayNode : AudioNode {

    readonly attribute AudioParam delayTime;

};

interface AudioBuffer {

    readonly attribute float sampleRate;
    readonly attribute long length;

    // in seconds 
    readonly attribute double duration;

    readonly attribute long numberOfChannels;

    Float32Array getChannelData(unsigned long channel);

};

    numberOfInputs  : 0
    numberOfOutputs : 1
    

interface AudioBufferSourceNode : AudioNode {

    attribute AudioBuffer? buffer;

    readonly attribute AudioParam playbackRate;

    attribute boolean loop;
    attribute double loopStart;
    attribute double loopEnd;

    void start(optional double when = 0, optional double offset = 0, optional double duration);
    void stop(optional double when = 0);

    attribute EventHandler onended;

};

    numberOfInputs  : 0
    numberOfOutputs : 1
    

interface MediaElementAudioSourceNode : AudioNode {

};

A MediaElementAudioSourceNode is created given an HTMLMediaElement using the AudioContext createMediaElementSource() method.

The number of channels of the single output equals the number of channels of the audio referenced by the HTMLMediaElement passed in as the argument to createMediaElementSource(), or is 1 if the HTMLMediaElement has no audio.

The HTMLMediaElement must behave in an identical fashion after the MediaElementAudioSourceNode has been created, except that the rendered audio will no longer be heard directly, but instead will be heard as a consequence of the MediaElementAudioSourceNode being connected through the routing graph. Thus pausing, seeking, volume, .src attribute changes, and other aspects of the HTMLMediaElement must behave as they normally would if not used with a MediaElementAudioSourceNode.

 
var mediaElement = document.getElementById('mediaElementID');
var sourceNode = context.createMediaElementSource(mediaElement);
sourceNode.connect(filterNode);
 

4.12. The ScriptProcessorNode Interface

This interface is an AudioNode which can generate, process, or analyse audio directly using JavaScript.

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCount = numberOfInputChannels;
    channelCountMode = "explicit";
    channelInterpretation = "speakers";

The ScriptProcessorNode is constructed with a bufferSize which must be one of the following values: 256, 512, 1024, 2048, 4096, 8192, 16384. This value controls how frequently the audioprocess event is dispatched and how many sample-frames need to be processed each call. audioprocess events are only dispatched if the ScriptProcessorNode has at least one input or one output connected. Lower numbers for bufferSize will result in a lower (better) latency. Higher numbers will be necessary to avoid audio breakup and glitches. This value will be picked by the implementation if the bufferSize argument to createScriptProcessor is not passed in, or is set to 0.

numberOfInputChannels and numberOfOutputChannels determine the number of input and output channels. It is invalid for both numberOfInputChannels and numberOfOutputChannels to be zero.

    var node = context.createScriptProcessor(bufferSize, numberOfInputChannels, numberOfOutputChannels);
    

interface ScriptProcessorNode : AudioNode {

    attribute EventHandler onaudioprocess;

    readonly attribute long bufferSize;

};

4.13. The AudioProcessingEvent Interface

This is an Event object which is dispatched to ScriptProcessorNode nodes.

The event handler processes audio from the input (if any) by accessing the audio data from the inputBuffer attribute. The audio data which is the result of the processing (or the synthesized data if there are no inputs) is then placed into the outputBuffer.

interface AudioProcessingEvent : Event {

    readonly attribute double playbackTime;
    readonly attribute AudioBuffer inputBuffer;
    readonly attribute AudioBuffer outputBuffer;

};

4.14. The PannerNode Interface

This interface represents a processing node which positions / spatializes an incoming audio stream in three-dimensional space. The spatialization is in relation to the AudioContext's AudioListener (listener attribute).

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCount = 2;
    channelCountMode = "clamped-max";
    channelInterpretation = "speakers";

The audio stream from the input will be either mono or stereo, depending on the connection(s) to the input.

The output of this node is hard-coded to stereo (2 channels) and currently cannot be configured.

enum PanningModelType {
  "equalpower",
  "HRTF"
};

enum DistanceModelType {
  "linear",
  "inverse",
  "exponential"
};

interface PannerNode : AudioNode {

    // Default for stereo is HRTF 
    attribute PanningModelType panningModel;

    // Uses a 3D cartesian coordinate system 
    void setPosition(double x, double y, double z);
    void setOrientation(double x, double y, double z);
    void setVelocity(double x, double y, double z);

    // Distance model and attributes 
    attribute DistanceModelType distanceModel;
    attribute double refDistance;
    attribute double maxDistance;
    attribute double rolloffFactor;

    // Directional sound cone 
    attribute double coneInnerAngle;
    attribute double coneOuterAngle;
    attribute double coneOuterGain;

};

4.14.2. Attributes

panningModel

Determines which spatialization algorithm will be used to position the audio in 3D space. The default is "HRTF".

"equalpower"

A simple and efficient spatialization algorithm using equal-power panning.

"HRTF"

A higher quality spatialization algorithm using a convolution with measured impulse responses from human subjects. This panning method renders stereo output.

distanceModel

Determines which algorithm will be used to reduce the volume of an audio source as it moves away from the listener. The default is "inverse".

"linear"

A linear distance model which calculates distanceGain according to:

1 - rolloffFactor * (distance - refDistance) / (maxDistance - refDistance)
    

"inverse"

An inverse distance model which calculates distanceGain according to:

refDistance / (refDistance + rolloffFactor * (distance - refDistance))
    

"exponential"

An exponential distance model which calculates distanceGain according to:

pow(distance / refDistance, -rolloffFactor)
  

refDistance

A reference distance for reducing volume as source move further from the listener. The default value is 1.

maxDistance

The maximum distance between source and listener, after which the volume will not be reduced any further. The default value is 10000.

rolloffFactor

Describes how quickly the volume is reduced as source moves away from listener. The default value is 1.

coneInnerAngle

A parameter for directional audio sources, this is an angle, inside of which there will be no volume reduction. The default value is 360.

coneOuterAngle

A parameter for directional audio sources, this is an angle, outside of which the volume will be reduced to a constant value of coneOuterGain. The default value is 360.

coneOuterGain

A parameter for directional audio sources, this is the amount of volume reduction outside of the coneOuterAngle. The default value is 0.

4.15. The AudioListener Interface

This interface represents the position and orientation of the person listening to the audio scene. All PannerNode objects spatialize in relation to the AudioContext's listener. See this section for more details about spatialization.

interface AudioListener {

    attribute double dopplerFactor;
    attribute double speedOfSound;

    // Uses a 3D cartesian coordinate system 
    void setPosition(double x, double y, double z);
    void setOrientation(double x, double y, double z, double xUp, double yUp, double zUp);
    void setVelocity(double x, double y, double z);

};

4.15.1. Attributes

dopplerFactor

A constant used to determine the amount of pitch shift to use when rendering a doppler effect. The default value is 1.

speedOfSound

The speed of sound used for calculating doppler shift. The default value is 343.3.

4.16. The ConvolverNode Interface

This interface represents a processing node which applies a linear convolution effect given an impulse response. Normative requirements for multi-channel convolution matrixing are described here.

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCount = 2;
    channelCountMode = "clamped-max";
    channelInterpretation = "speakers";

interface ConvolverNode : AudioNode {

    attribute AudioBuffer? buffer;
    attribute boolean normalize;

};

4.16.1. Attributes

buffer

A mono, stereo, or 4-channel AudioBuffer containing the (possibly multi-channel) impulse response used by the ConvolverNode. This AudioBuffer must be of the same sample-rate as the AudioContext or an NOT_SUPPORTED_ERR exception MUST be thrown. At the time when this attribute is set, the buffer and the state of the normalize attribute will be used to configure the ConvolverNode with this impulse response having the given normalization. The initial value of this attribute is null.

normalize

Controls whether the impulse response from the buffer will be scaled by an equal-power normalization when the buffer atttribute is set. Its default value is true in order to achieve a more uniform output level from the convolver when loaded with diverse impulse responses. If normalize is set to false, then the convolution will be rendered with no pre-processing/scaling of the impulse response. Changes to this value do not take effect until the next time the buffer attribute is set.

If the normalize attribute is false when the buffer attribute is set then the ConvolverNode will perform a linear convolution given the exact impulse response contained within the buffer.

Otherwise, if the normalize attribute is true when the buffer attribute is set then the ConvolverNode will first perform a scaled RMS-power analysis of the audio data contained within buffer to calculate a normalizationScale given this algorithm:

 

float calculateNormalizationScale(buffer)
{
    const float GainCalibration = 0.00125;
    const float GainCalibrationSampleRate = 44100;
    const float MinPower = 0.000125;
  
    // Normalize by RMS power.
    size_t numberOfChannels = buffer->numberOfChannels();
    size_t length = buffer->length();

    float power = 0;

    for (size_t i = 0; i < numberOfChannels; ++i) {
        float* sourceP = buffer->channel(i)->data();
        float channelPower = 0;

        int n = length;
        while (n--) {
            float sample = *sourceP++;
            channelPower += sample * sample;
        }

        power += channelPower;
    }

    power = sqrt(power / (numberOfChannels * length));

    // Protect against accidental overload.
    if (isinf(power) || isnan(power) || power < MinPower)
        power = MinPower;

    float scale = 1 / power;

    // Calibrate to make perceived volume same as unprocessed.
    scale *= GainCalibration;

    // Scale depends on sample-rate.
    if (buffer->sampleRate())
        scale *= GainCalibrationSampleRate / buffer->sampleRate();

    // True-stereo compensation.
    if (buffer->numberOfChannels() == 4)
        scale *= 0.5;

    return scale;
}
          

During processing, the ConvolverNode will then take this calculated normalizationScale value and multiply it by the result of the linear convolution resulting from processing the input with the impulse response (represented by the buffer) to produce the final output. Or any mathematically equivalent operation may be used, such as pre-multiplying the input by normalizationScale, or pre-multiplying a version of the impulse-response by normalizationScale.

4.17. The AnalyserNode Interface

This interface represents a node which is able to provide real-time frequency and time-domain analysis information. The audio stream will be passed un-processed from input to output.

    numberOfInputs  : 1
    numberOfOutputs : 1    Note that this output may be left unconnected.

    channelCount = 1;
    channelCountMode = "explicit";
    channelInterpretation = "speakers";

interface AnalyserNode : AudioNode {

    // Real-time frequency-domain data 
    void getFloatFrequencyData(Float32Array array);
    void getByteFrequencyData(Uint8Array array);

    // Real-time waveform data 
    void getByteTimeDomainData(Uint8Array array);

    attribute unsigned long fftSize;
    readonly attribute unsigned long frequencyBinCount;

    attribute double minDecibels;
    attribute double maxDecibels;

    attribute double smoothingTimeConstant;

};

4.17.1. Attributes

fftSize

The size of the FFT used for frequency-domain analysis. This must be a non-zero power of two in the range 32 to 2048, otherwise an INDEX_SIZE_ERR exception MUST be thrown. The default value is 2048.

frequencyBinCount

Half the FFT size.

minDecibels

The minimum power value in the scaling range for the FFT analysis data for conversion to unsigned byte values. The default value is -100. If the value of this attribute is set to a value more than or equal to maxDecibels, an INDEX_SIZE_ERR exception MUST be thrown.

maxDecibels

The maximum power value in the scaling range for the FFT analysis data for conversion to unsigned byte values. The default value is -30. If the value of this attribute is set to a value less than or equal to minDecibels, an INDEX_SIZE_ERR exception MUST be thrown.

smoothingTimeConstant

A value from 0 -> 1 where 0 represents no time averaging with the last analysis frame. The default value is 0.8. If the value of this attribute is set to a value less than 0 or more than 1, an INDEX_SIZE_ERR exception MUST be thrown.

4.18. The ChannelSplitterNode Interface

The ChannelSplitterNode is for use in more advanced applications and would often be used in conjunction with ChannelMergerNode.

    numberOfInputs  : 1
    numberOfOutputs : Variable N (defaults to 6) // number of "active" (non-silent) outputs is determined by number of channels in the input

    channelCountMode = "max";
    channelInterpretation = "speakers";

This interface represents an AudioNode for accessing the individual channels of an audio stream in the routing graph. It has a single input, and a number of "active" outputs which equals the number of channels in the input audio stream. For example, if a stereo input is connected to an ChannelSplitterNode then the number of active outputs will be two (one from the left channel and one from the right). There are always a total number of N outputs (determined by the numberOfOutputs parameter to the AudioContext method createChannelSplitter()), The default number is 6 if this value is not provided. Any outputs which are not "active" will output silence and would typically not be connected to anything.

Example:

Please note that in this example, the splitter does not interpret the channel identities (such as left, right, etc.), but simply splits out channels in the order that they are input.

One application for ChannelSplitterNode is for doing "matrix mixing" where individual gain control of each channel is desired.

interface ChannelSplitterNode : AudioNode {

};

4.19. The ChannelMergerNode Interface

The ChannelMergerNode is for use in more advanced applications and would often be used in conjunction with ChannelSplitterNode.

    numberOfInputs  : Variable N (default to 6)  // number of connected inputs may be less than this
    numberOfOutputs : 1

    channelCountMode = "max";
    channelInterpretation = "speakers";

This interface represents an AudioNode for combining channels from multiple audio streams into a single audio stream. It has a variable number of inputs (defaulting to 6), but not all of them need be connected. There is a single output whose audio stream has a number of channels equal to the sum of the numbers of channels of all the connected inputs. For example, if an ChannelMergerNode has two connected inputs (both stereo), then the output will be four channels, the first two from the first input and the second two from the second input. In another example with two connected inputs (both mono), the output will be two channels (stereo), with the left channel coming from the first input and the right channel coming from the second input.

Example:

Please note that in this example, the merger does not interpret the channel identities (such as left, right, etc.), but simply combines channels in the order that they are input.

Be aware that it is possible to connect an ChannelMergerNode in such a way that it outputs an audio stream with a large number of channels greater than the maximum supported by the audio hardware. In this case where such an output is connected to the AudioContext .destination (the audio hardware), then the extra channels will be ignored. Thus, the ChannelMergerNode should be used in situations where the number of channels is well understood.

interface ChannelMergerNode : AudioNode {

};

4.20. The DynamicsCompressorNode Interface

DynamicsCompressorNode is an AudioNode processor implementing a dynamics compression effect.

Dynamics compression is very commonly used in musical production and game audio. It lowers the volume of the loudest parts of the signal and raises the volume of the softest parts. Overall, a louder, richer, and fuller sound can be achieved. It is especially important in games and musical applications where large numbers of individual sounds are played simultaneous to control the overall signal level and help avoid clipping (distorting) the audio output to the speakers.

    
    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCount = 2;
    channelCountMode = "explicit";
    channelInterpretation = "speakers";

interface DynamicsCompressorNode : AudioNode {

    readonly attribute AudioParam threshold; // in Decibels
    readonly attribute AudioParam knee; // in Decibels
    readonly attribute AudioParam ratio; // unit-less
    readonly attribute AudioParam reduction; // in Decibels
    readonly attribute AudioParam attack; // in Seconds
    readonly attribute AudioParam release; // in Seconds

};

4.21. The BiquadFilterNode Interface

BiquadFilterNode is an AudioNode processor implementing very common low-order filters.

Low-order filters are the building blocks of basic tone controls (bass, mid, treble), graphic equalizers, and more advanced filters. Multiple BiquadFilterNode filters can be combined to form more complex filters. The filter parameters such as "frequency" can be changed over time for filter sweeps, etc. Each BiquadFilterNode can be configured as one of a number of common filter types as shown in the IDL below. The default filter type is "lowpass".

    
    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCountMode = "max";
    channelInterpretation = "speakers";

The number of channels of the output always equals the number of channels of the input.

enum BiquadFilterType {
  "lowpass",
  "highpass",
  "bandpass",
  "lowshelf",
  "highshelf",
  "peaking",
  "notch",
  "allpass"
};

interface BiquadFilterNode : AudioNode {

    attribute BiquadFilterType type;
    readonly attribute AudioParam frequency; // in Hertz
    readonly attribute AudioParam detune; // in Cents
    readonly attribute AudioParam Q; // Quality factor
    readonly attribute AudioParam gain; // in Decibels

    void getFrequencyResponse(Float32Array frequencyHz,
                              Float32Array magResponse,
                              Float32Array phaseResponse);

};

4.21.1 "lowpass"

A lowpass filter allows frequencies below the cutoff frequency to pass through and attenuates frequencies above the cutoff. It implements a standard second-order resonant lowpass filter with 12dB/octave rolloff.

frequency

The cutoff frequency

Q

Controls how peaked the response will be at the cutoff frequency. A large value makes the response more peaked. Please note that for this filter type, this value is not a traditional Q, but is a resonance value in decibels.

gain

Not used in this filter type

4.21.2 "highpass"

A highpass filter is the opposite of a lowpass filter. Frequencies above the cutoff frequency are passed through, but frequencies below the cutoff are attenuated. It implements a standard second-order resonant highpass filter with 12dB/octave rolloff.

frequency

The cutoff frequency below which the frequencies are attenuated

Q

Controls how peaked the response will be at the cutoff frequency. A large value makes the response more peaked. Please note that for this filter type, this value is not a traditional Q, but is a resonance value in decibels.

gain

Not used in this filter type

4.21.3 "bandpass"

A bandpass filter allows a range of frequencies to pass through and attenuates the frequencies below and above this frequency range. It implements a second-order bandpass filter.

frequency

The center of the frequency band

Q

Controls the width of the band. The width becomes narrower as the Q value increases.

gain

Not used in this filter type

4.21.4 "lowshelf"

The lowshelf filter allows all frequencies through, but adds a boost (or attenuation) to the lower frequencies. It implements a second-order lowshelf filter.

frequency

The upper limit of the frequences where the boost (or attenuation) is applied.

Q

Not used in this filter type.

gain

The boost, in dB, to be applied. If the value is negative, the frequencies are attenuated.

4.21.5 "highshelf"

The highshelf filter is the opposite of the lowshelf filter and allows all frequencies through, but adds a boost to the higher frequencies. It implements a second-order highshelf filter

frequency

The lower limit of the frequences where the boost (or attenuation) is applied.

Q

Not used in this filter type.

gain

The boost, in dB, to be applied. If the value is negative, the frequencies are attenuated.

4.21.6 "peaking"

The peaking filter allows all frequencies through, but adds a boost (or attenuation) to a range of frequencies.

frequency

The center frequency of where the boost is applied.

Q

Controls the width of the band of frequencies that are boosted. A large value implies a narrow width.

gain

The boost, in dB, to be applied. If the value is negative, the frequencies are attenuated.

4.21.7 "notch"

The notch filter (also known as a band-stop or band-rejection filter) is the opposite of a bandpass filter. It allows all frequencies through, except for a set of frequencies.

frequency

The center frequency of where the notch is applied.

Q

Controls the width of the band of frequencies that are attenuated. A large value implies a narrow width.

gain

Not used in this filter type.

4.21.8 "allpass"

An allpass filter allows all frequencies through, but changes the phase relationship between the various frequencies. It implements a second-order allpass filter

frequency

The frequency where the center of the phase transition occurs. Viewed another way, this is the frequency with maximal group delay.

Q

Controls how sharp the phase transition is at the center frequency. A larger value implies a sharper transition and a larger group delay.

gain

Not used in this filter type.

4.21.9. Methods

The getFrequencyResponse method

Given the current filter parameter settings, calculates the frequency response for the specified frequencies.

The frequencyHz parameter specifies an array of frequencies at which the response values will be calculated.

The magResponse parameter specifies an output array receiving the linear magnitude response values.

The phaseResponse parameter specifies an output array receiving the phase response values in radians.

4.22. The WaveShaperNode Interface

WaveShaperNode is an AudioNode processor implementing non-linear distortion effects.

Non-linear waveshaping distortion is commonly used for both subtle non-linear warming, or more obvious distortion effects. Arbitrary non-linear shaping curves may be specified.

    numberOfInputs  : 1
    numberOfOutputs : 1

    channelCountMode = "max";
    channelInterpretation = "speakers";

The number of channels of the output always equals the number of channels of the input.

enum OverSampleType {
    "none",
    "2x",
    "4x"
};

interface WaveShaperNode : AudioNode {

    attribute Float32Array? curve;
    attribute OverSampleType oversample;

};

4.23. The OscillatorNode Interface

OscillatorNode represents an audio source generating a periodic waveform. It can be set to a few commonly used waveforms. Additionally, it can be set to an arbitrary periodic waveform through the use of a PeriodicWave object.

Oscillators are common foundational building blocks in audio synthesis. An OscillatorNode will start emitting sound at the time specified by the start() method.

Mathematically speaking, a continuous-time periodic waveform can have very high (or infinitely high) frequency information when considered in the frequency domain. When this waveform is sampled as a discrete-time digital audio signal at a particular sample-rate, then care must be taken to discard (filter out) the high-frequency information higher than the Nyquist frequency (half the sample-rate) before converting the waveform to a digital form. If this is not done, then aliasing of higher frequencies (than the Nyquist frequency) will fold back as mirror images into frequencies lower than the Nyquist frequency. In many cases this will cause audibly objectionable artifacts. This is a basic and well understood principle of audio DSP.

There are several practical approaches that an implementation may take to avoid this aliasing. But regardless of approach, the idealized discrete-time digital audio signal is well defined mathematically. The trade-off for the implementation is a matter of implementation cost (in terms of CPU usage) versus fidelity to achieving this ideal.

It is expected that an implementation will take some care in achieving this ideal, but it is reasonable to consider lower-quality, less-costly approaches on lower-end hardware.

Both .frequency and .detune are a-rate parameters and are used together to determine a computedFrequency value:

computedFrequency(t) = frequency(t) * pow(2, detune(t) / 1200)

The OscillatorNode's instantaneous phase at each time is the time integral of computedFrequency.

    numberOfInputs  : 0
    numberOfOutputs : 1 (mono output)
    

enum OscillatorType {
  "sine",
  "square",
  "sawtooth",
  "triangle",
  "custom"
};

interface OscillatorNode : AudioNode {

    attribute OscillatorType type;

    readonly attribute AudioParam frequency; // in Hertz
    readonly attribute AudioParam detune; // in Cents

    void start(double when);
    void stop(double when);
    void setPeriodicWave(PeriodicWave periodicWave);

    attribute EventHandler onended;

};

4.23.2. Methods and Parameters

The setPeriodicWave method

Sets an arbitrary custom periodic waveform given a PeriodicWave.

The start method

defined as in AudioBufferSourceNode.

The stop method

defined as in AudioBufferSourceNode.

4.24. The PeriodicWave Interface

PeriodicWave represents an arbitrary periodic waveform to be used with an OscillatorNode. Please see createPeriodicWave() and setPeriodicWave() and for more details.

interface PeriodicWave {

};

4.25. The MediaStreamAudioSourceNode Interface

This interface represents an audio source from a MediaStream. The first AudioMediaStreamTrack from the MediaStream will be used as a source of audio.

    numberOfInputs  : 0
    numberOfOutputs : 1

The number of channels of the output corresponds to the number of channels of the AudioMediaStreamTrack. If there is no valid audio track, then the number of channels output will be one silent channel.

interface MediaStreamAudioSourceNode : AudioNode {

};

4.26. The MediaStreamAudioDestinationNode Interface

This interface is an audio destination representing a MediaStream with a single AudioMediaStreamTrack. This MediaStream is created when the node is created and is accessible via the stream attribute. This stream can be used in a similar way as a MediaStream obtained via getUserMedia(), and can, for example, be sent to a remote peer using the RTCPeerConnection addStream() method.

    numberOfInputs  : 1
    numberOfOutputs : 0

    channelCount = 2;
    channelCountMode = "explicit";
    channelInterpretation = "speakers";

The number of channels of the input is by default 2 (stereo). Any connections to the input are up-mixed/down-mixed to the number of channels of the input.

interface MediaStreamAudioDestinationNode : AudioNode {

    readonly attribute MediaStream stream;

};

6. Mixer Gain Structure

This section is informative.

Background

One of the most important considerations when dealing with audio processing graphs is how to adjust the gain (volume) at various points. For example, in a standard mixing board model, each input bus has pre-gain, post-gain, and send-gains. Submix and master out busses also have gain control. The gain control described here can be used to implement standard mixing boards as well as other architectures.

The inputs to AudioNodes have the ability to accept connections from multiple outputs. The input then acts as a unity gain summing junction with each output signal being added with the others:

In cases where the channel layouts of the outputs do not match, a mix (usually up-mix) will occur according to the mixing rules.

Gain Control

But many times, it's important to be able to control the gain for each of the output signals. The GainNode gives this control:

Using these two concepts of unity gain summing junctions and GainNodes, it's possible to construct simple or complex mixing scenarios.

Example: Mixer with Send Busses

In a routing scenario involving multiple sends and submixes, explicit control is needed over the volume or "gain" of each connection to a mixer. Such routing topologies are very common and exist in even the simplest of electronic gear sitting around in a basic recording studio.

Here's an example with two send mixers and a main mixer. Although possible, for simplicity's sake, pre-gain control and insert effects are not illustrated:

This diagram is using a shorthand notation where "send 1", "send 2", and "main bus" are actually inputs to AudioNodes, but here are represented as summing busses, where the intersections g2_1, g3_1, etc. represent the "gain" or volume for the given source on the given mixer. In order to expose this gain, an GainNode is used:

Here's how the above diagram could be constructed in JavaScript:

 

var context = 0;
var compressor = 0;
var reverb = 0;
var delay = 0;
var s1 = 0;
var s2 = 0;

var source1 = 0;
var source2 = 0;
var g1_1 = 0;
var g2_1 = 0;
var g3_1 = 0;
var g1_2 = 0;
var g2_2 = 0;
var g3_2 = 0;

// Setup routing graph 
function setupRoutingGraph() {
    context = new AudioContext();

    compressor = context.createDynamicsCompressor();

    // Send1 effect 
    reverb = context.createConvolver();
    // Convolver impulse response may be set here or later 

    // Send2 effect 
    delay = context.createDelay();

    // Connect final compressor to final destination 
    compressor.connect(context.destination);

    // Connect sends 1 & 2 through effects to main mixer 
    s1 = context.createGain();
    reverb.connect(s1);
    s1.connect(compressor);
    
    s2 = context.createGain();
    delay.connect(s2);
    s2.connect(compressor);

    // Create a couple of sources 
    source1 = context.createBufferSource();
    source2 = context.createBufferSource();
    source1.buffer = manTalkingBuffer;
    source2.buffer = footstepsBuffer;

    // Connect source1 
    g1_1 = context.createGain();
    g2_1 = context.createGain();
    g3_1 = context.createGain();
    source1.connect(g1_1);
    source1.connect(g2_1);
    source1.connect(g3_1);
    g1_1.connect(compressor);
    g2_1.connect(reverb);
    g3_1.connect(delay);

    // Connect source2 
    g1_2 = context.createGain();
    g2_2 = context.createGain();
    g3_2 = context.createGain();
    source2.connect(g1_2);
    source2.connect(g2_2);
    source2.connect(g3_2);
    g1_2.connect(compressor);
    g2_2.connect(reverb);
    g3_2.connect(delay);

    // We now have explicit control over all the volumes g1_1, g2_1, ..., s1, s2 
    g2_1.gain.value = 0.2;  // For example, set source1 reverb gain 

     // Because g2_1.gain is an "AudioParam", 
     // an automation curve could also be attached to it. 
     // A "mixing board" UI could be created in canvas or WebGL controlling these gains. 
}

 

9. Channel up-mixing and down-mixing

This section is normative.

Mixer Gain Structure describes how an input to an AudioNode can be connected from one or more outputs of an AudioNode. Each of these connections from an output represents a stream with a specific non-zero number of channels. An input has mixing rules for combining the channels from all of the connections to it. As a simple example, if an input is connected from a mono output and a stereo output, then the mono connection will usually be up-mixed to stereo and summed with the stereo connection. But, of course, it's important to define the exact mixing rules for every input to every AudioNode. The default mixing rules for all of the inputs have been chosen so that things "just work" without worrying too much about the details, especially in the very common case of mono and stereo streams. But the rules can be changed for advanced use cases, especially multi-channel.

To define some terms, up-mixing refers to the process of taking a stream with a smaller number of channels and converting it to a stream with a larger number of channels. down-mixing refers to the process of taking a stream with a larger number of channels and converting it to a stream with a smaller number of channels.

An AudioNode input use three basic pieces of information to determine how to mix all the outputs connected to it. As part of this process it computes an internal value computedNumberOfChannels representing the actual number of channels of the input at any given time:

The AudioNode attributes involved in channel up-mixing and down-mixing rules are defined above. The following is a more precise specification on what each of them mean.

• channelCount is used to help compute computedNumberOfChannels.
• channelCountMode determines how computedNumberOfChannels will be computed. Once this number is computed, all of the connections will be up or down-mixed to that many channels. For most nodes, the default value is "max".
  • “max”: computedNumberOfChannels is computed as the maximum of the number of channels of all connections. In this mode channelCount is ignored.
  • “clamped-max”: same as “max” up to a limit of the channelCount
  • “explicit”: computedNumberOfChannels is the exact value as specified in channelCount
• channelInterpretation determines how the individual channels will be treated. For example, will they be treated as speakers having a specific layout, or will they be treated as simple discrete channels? This value influences exactly how the up and down mixing is performed. The default value is "speakers".
  • “speakers”: use up-down-mix equations for mono/stereo/quad/5.1. In cases where the number of channels do not match any of these basic speaker layouts, revert to "discrete".
  • “discrete”: up-mix by filling channels until they run out then zero out remaining channels. down-mix by filling as many channels as possible, then dropping remaining channels

For each input of an AudioNode, an implementation must:

1. Compute computedNumberOfChannels.
2. For each connection to the input:
   • up-mix or down-mix the connection to computedNumberOfChannels according to channelInterpretation.
   • Mix it together with all of the other mixed streams (from other connections). This is a straight-forward mixing together of each of the corresponding channels from each connection.

  Mono
    0: M: mono
    
  Stereo
    0: L: left
    1: R: right
  

  Quad
    0: L:  left
    1: R:  right
    2: SL: surround left
    3: SR: surround right

  5.1
    0: L:   left
    1: R:   right
    2: C:   center
    3: LFE: subwoofer
    4: SL:  surround left
    5: SR:  surround right
  

9.1.2. Up Mixing speaker layouts

Mono up-mix:
    
    1 -> 2 : up-mix from mono to stereo
        output.L = input;
        output.R = input;

    1 -> 4 : up-mix from mono to quad
        output.L = input;
        output.R = input;
        output.SL = 0;
        output.SR = 0;

    1 -> 5.1 : up-mix from mono to 5.1
        output.L = 0;
        output.R = 0;
        output.C = input; // put in center channel
        output.LFE = 0;
        output.SL = 0;
        output.SR = 0;

Stereo up-mix:

    2 -> 4 : up-mix from stereo to quad
        output.L = input.L;
        output.R = input.R;
        output.SL = 0;
        output.SR = 0;

    2 -> 5.1 : up-mix from stereo to 5.1
        output.L = input.L;
        output.R = input.R;
        output.C = 0;
        output.LFE = 0;
        output.SL = 0;
        output.SR = 0;

Quad up-mix:

    4 -> 5.1 : up-mix from quad to 5.1
        output.L = input.L;
        output.R = input.R;
        output.C = 0;
        output.LFE = 0;
        output.SL = input.SL;
        output.SR = input.SR;

9.1.3. Down Mixing speaker layouts

A down-mix will be necessary, for example, if processing 5.1 source material, but playing back stereo.

  
Mono down-mix:

    2 -> 1 : stereo to mono
        output = 0.5 * (input.L + input.R);

    4 -> 1 : quad to mono
        output = 0.25 * (input.L + input.R + input.SL + input.SR);

    5.1 -> 1 : 5.1 to mono
        output = 0.7071 * (input.L + input.R) + input.C + 0.5 * (input.SL + input.SR)


Stereo down-mix:

    4 -> 2 : quad to stereo
        output.L = 0.5 * (input.L + input.SL);
        output.R = 0.5 * (input.R + input.SR);

    5.1 -> 2 : 5.1 to stereo
        output.L = L + 0.7071 * (input.C + input.SL)
        output.R = R + 0.7071 * (input.C + input.SR)

Quad down-mix:

    5.1 -> 4 : 5.1 to quad
        output.L = L + 0.7071 * input.C
        output.R = R + 0.7071 * input.C
        output.SL = input.SL
        output.SR = input.SR

11. Spatialization / Panning

Background

A common feature requirement for modern 3D games is the ability to dynamically spatialize and move multiple audio sources in 3D space. Game audio engines such as OpenAL, FMOD, Creative's EAX, Microsoft's XACT Audio, etc. have this ability.

Using an PannerNode, an audio stream can be spatialized or positioned in space relative to an AudioListener. An AudioContext will contain a single AudioListener. Both panners and listeners have a position in 3D space using a right-handed cartesian coordinate system. The units used in the coordinate system are not defined, and do not need to be because the effects calculated with these coordinates are independent/invariant of any particular units such as meters or feet. PannerNode objects (representing the source stream) have an orientation vector representing in which direction the sound is projecting. Additionally, they have a sound cone representing how directional the sound is. For example, the sound could be omnidirectional, in which case it would be heard anywhere regardless of its orientation, or it can be more directional and heard only if it is facing the listener. AudioListener objects (representing a person's ears) have an orientation and up vector representing in which direction the person is facing. Because both the source stream and the listener can be moving, they both have a velocity vector representing both the speed and direction of movement. Taken together, these two velocities can be used to generate a doppler shift effect which changes the pitch.

During rendering, the PannerNode calculates an azimuth and elevation. These values are used internally by the implementation in order to render the spatialization effect. See the Panning Algorithm section for details of how these values are used.

The following algorithm must be used to calculate the azimuth and elevation:

 
// Calculate the source-listener vector.
vec3 sourceListener = source.position - listener.position;

if (sourceListener.isZero()) {
    // Handle degenerate case if source and listener are at the same point.
    azimuth = 0;
    elevation = 0;
    return;
}

sourceListener.normalize();

// Align axes.
vec3 listenerFront = listener.orientation;
vec3 listenerUp = listener.up;
vec3 listenerRight = listenerFront.cross(listenerUp);
listenerRight.normalize();

vec3 listenerFrontNorm = listenerFront;
listenerFrontNorm.normalize();

vec3 up = listenerRight.cross(listenerFrontNorm);

float upProjection = sourceListener.dot(up);

vec3 projectedSource = sourceListener - upProjection * up;
projectedSource.normalize();

azimuth = 180 * acos(projectedSource.dot(listenerRight)) / PI;

// Source in front or behind the listener.
double frontBack = projectedSource.dot(listenerFrontNorm);
if (frontBack < 0)
    azimuth = 360 - azimuth;

// Make azimuth relative to "front" and not "right" listener vector.
if ((azimuth >= 0) && (azimuth <= 270))
    azimuth = 90 - azimuth;
else
    azimuth = 450 - azimuth;

elevation = 90 - 180 * acos(sourceListener.dot(up)) / PI;

if (elevation > 90)
    elevation = 180 - elevation;
else if (elevation < -90)
    elevation = -180 - elevation;

Panning Algorithm

mono->stereo and stereo->stereo panning must be supported. mono->stereo processing is used when all connections to the input are mono. Otherwise stereo->stereo processing is used.

The following algorithms must be implemented:

• Equal-power (Vector-based) panning

  This is a simple and relatively inexpensive algorithm which provides basic, but reasonable results. It is commonly used when panning musical sources.

  The elevation value is ignored in this panning algorithm.

  The following steps are used for processing:

  1. The azimuth value is first contained to be within the range -90 <= azimuth <= +90 according to:

         // Clamp azimuth to allowed range of -180 -> +180.
         azimuth = max(-180, azimuth);
         azimuth = min(180, azimuth);
     
         // Now wrap to range -90 -> +90.
         if (azimuth < -90)
             azimuth = -180 - azimuth;
         else if (azimuth > 90)
             azimuth = 180 - azimuth;
         

  2. A 0 -> 1 normalized value x is calculated from azimuth for mono->stereo as:

         x = (azimuth + 90) / 180    
         

     Or for stereo->stereo as:

         if (azimuth <= 0) { // from -90 -> 0
             // inputL -> outputL and "equal-power pan" inputR as in mono case
             // by transforming the "azimuth" value from -90 -> 0 degrees into the range -90 -> +90.
             x = (azimuth + 90) / 90;
         } else { // from 0 -> +90
             // inputR -> outputR and "equal-power pan" inputL as in mono case
             // by transforming the "azimuth" value from 0 -> +90 degrees into the range -90 -> +90.
             x = azimuth / 90;
         }
         

  3. Left and right gain values are then calculated:

         gainL = cos(0.5 * PI * x);
         gainR = sin(0.5 * PI * x);    
         

  4. For mono->stereo, the output is calculated as:

         outputL = input * gainL
         outputR = input * gainR
         

     Else for stereo->stereo, the output is calculated as:

         if (azimuth <= 0) { // from -90 -> 0
             outputL = inputL + inputR * gainL;
             outputR = inputR * gainR;
         } else { // from 0 -> +90
             outputL = inputL * gainL;
             outputR = inputR + inputL * gainR;
         }
         

• HRTF panning (stereo only)

  This requires a set of HRTF impulse responses recorded at a variety of azimuths and elevations. There are a small number of open/free impulse responses available. The implementation requires a highly optimized convolution function. It is somewhat more costly than "equal-power", but provides a more spatialized sound.

  

Distance Effects

Sounds which are closer are louder, while sounds further away are quieter. Exactly how a sound's volume changes according to distance from the listener depends on the distanceModel attribute.

During audio rendering, a distance value will be calculated based on the panner and listener positions according to:

v = panner.position - listener.position

distance = sqrt(dot(v, v))

distance will then be used to calculate distanceGain which depends on the distanceModel attribute. See the distanceModel section for details of how this is calculated for each distance model.

As part of its processing, the PannerNode scales/multiplies the input audio signal by distanceGain to make distant sounds quieter and nearer ones louder.

Sound Cones

The listener and each sound source have an orientation vector describing which way they are facing. Each sound source's sound projection characteristics are described by an inner and outer "cone" describing the sound intensity as a function of the source/listener angle from the source's orientation vector. Thus, a sound source pointing directly at the listener will be louder than if it is pointed off-axis. Sound sources can also be omni-directional.

The following algorithm must be used to calculate the gain contribution due to the cone effect, given the source (the PannerNode) and the listener:

 
if (source.orientation.isZero() || ((source.coneInnerAngle == 360) && (source.coneOuterAngle == 360)))
    return 1; // no cone specified - unity gain

// Normalized source-listener vector
vec3 sourceToListener = listener.position - source.position;
sourceToListener.normalize();

vec3 normalizedSourceOrientation = source.orientation;
normalizedSourceOrientation.normalize();

// Angle between the source orientation vector and the source-listener vector
double dotProduct = sourceToListener.dot(normalizedSourceOrientation);
double angle = 180 * acos(dotProduct) / PI;
double absAngle = fabs(angle);

// Divide by 2 here since API is entire angle (not half-angle)
double absInnerAngle = fabs(source.coneInnerAngle) / 2;
double absOuterAngle = fabs(source.coneOuterAngle) / 2;
double gain = 1;

if (absAngle <= absInnerAngle)
    // No attenuation
    gain = 1;
else if (absAngle >= absOuterAngle)
    // Max attenuation
    gain = source.coneOuterGain;
else {
    // Between inner and outer cones
    // inner -> outer, x goes from 0 -> 1
    double x = (absAngle - absInnerAngle) / (absOuterAngle - absInnerAngle);
    gain = (1 - x) + source.coneOuterGain * x;
}

return gain;

Doppler Shift

• Introduces a pitch shift which can realistically simulate moving sources.
• Depends on: source / listener velocity vectors, speed of sound, doppler factor.

The following algorithm must be used to calculate the doppler shift value which is used as an additional playback rate scalar for all AudioBufferSourceNodes connecting directly or indirectly to the AudioPannerNode:

 
double dopplerShift = 1; // Initialize to default value
double dopplerFactor = listener.dopplerFactor;

if (dopplerFactor > 0) {
    double speedOfSound = listener.speedOfSound;

    // Don't bother if both source and listener have no velocity.
    if (!source.velocity.isZero() || !listener.velocity.isZero()) {
        // Calculate the source to listener vector.
        vec3 sourceToListener = source.position - listener.position;

        double sourceListenerMagnitude = sourceToListener.length();

        double listenerProjection = sourceToListener.dot(listener.velocity) / sourceListenerMagnitude;
        double sourceProjection = sourceToListener.dot(source.velocity) / sourceListenerMagnitude;

        listenerProjection = -listenerProjection;
        sourceProjection = -sourceProjection;

        double scaledSpeedOfSound = speedOfSound / dopplerFactor;
        listenerProjection = min(listenerProjection, scaledSpeedOfSound);
        sourceProjection = min(sourceProjection, scaledSpeedOfSound);

        dopplerShift = ((speedOfSound - dopplerFactor * listenerProjection) / (speedOfSound - dopplerFactor * sourceProjection));
        fixNANs(dopplerShift); // Avoid illegal values

        // Limit the pitch shifting to 4 octaves up and 3 octaves down.
        dopplerShift = min(dopplerShift, 16);
        dopplerShift = max(dopplerShift, 0.125);
    }
}

12. Linear Effects using Convolution

Background

Convolution is a mathematical process which can be applied to an audio signal to achieve many interesting high-quality linear effects. Very often, the effect is used to simulate an acoustic space such as a concert hall, cathedral, or outdoor amphitheater. It can also be used for complex filter effects, like a muffled sound coming from inside a closet, sound underwater, sound coming through a telephone, or playing through a vintage speaker cabinet. This technique is very commonly used in major motion picture and music production and is considered to be extremely versatile and of high quality.

Each unique effect is defined by an impulse response. An impulse response can be represented as an audio file and can be recorded from a real acoustic space such as a cave, or can be synthetically generated through a great variety of techniques.

Motivation for use as a Standard

A key feature of many game audio engines (OpenAL, FMOD, Creative's EAX, Microsoft's XACT Audio, etc.) is a reverberation effect for simulating the sound of being in an acoustic space. But the code used to generate the effect has generally been custom and algorithmic (generally using a hand-tweaked set of delay lines and allpass filters which feedback into each other). In nearly all cases, not only is the implementation custom, but the code is proprietary and closed-source, each company adding its own "black magic" to achieve its unique quality. Each implementation being custom with a different set of parameters makes it impossible to achieve a uniform desired effect. And the code being proprietary makes it impossible to adopt a single one of the implementations as a standard. Additionally, algorithmic reverberation effects are limited to a relatively narrow range of different effects, regardless of how the parameters are tweaked.

A convolution effect solves these problems by using a very precisely defined mathematical algorithm as the basis of its processing. An impulse response represents an exact sound effect to be applied to an audio stream and is easily represented by an audio file which can be referenced by URL. The range of possible effects is enormous.

Implementation Guide

Linear convolution can be implemented efficiently. Here are some notes describing how it can be practically implemented.

Reverb Effect (with matrixing)

This section is normative.

In the general case the source has N input channels, the impulse response has K channels, and the playback system has M output channels. Thus it's a matter of how to matrix these channels to achieve the final result.

The subset of N, M, K below must be implemented (note that the first image in the diagram is just illustrating the general case and is not normative, while the following images are normative). Without loss of generality, developers desiring more complex and arbitrary matrixing can use multiple ConvolverNode objects in conjunction with an ChannelMergerNode.

Single channel convolution operates on a mono audio input, using a mono impulse response, and generating a mono output. But to achieve a more spacious sound, 2 channel audio inputs and 1, 2, or 4 channel impulse responses will be considered. The following diagram, illustrates the common cases for stereo playback where N and M are 1 or 2 and K is 1, 2, or 4.

Recording Impulse Responses

This section is informative.

The most modern and accurate way to record the impulse response of a real acoustic space is to use a long exponential sine sweep. The test-tone can be as long as 20 or 30 seconds, or longer.
Several recordings of the test tone played through a speaker can be made with microphones placed and oriented at various positions in the room. It's important to document speaker placement/orientation, the types of microphones, their settings, placement, and orientations for each recording taken.

Post-processing is required for each of these recordings by performing an inverse-convolution with the test tone, yielding the impulse response of the room with the corresponding microphone placement. These impulse responses are then ready to be loaded into the convolution reverb engine to re-create the sound of being in the room.

Tools

Two command-line tools have been written:
generate_testtones generates an exponential sine-sweep test-tone and its inverse. Another tool convolve was written for post-processing. With these tools, anybody with recording equipment can record their own impulse responses. To test the tools in practice, several recordings were made in a warehouse space with interesting acoustics. These were later post-processed with the command-line tools.

% generate_testtones -h
Usage: generate_testtone
	[-o /Path/To/File/To/Create] Two files will be created: .tone and .inverse
	[-rate <sample rate>] sample rate of the generated test tones
	[-duration <duration>] The duration, in seconds, of the generated files
	[-min_freq <min_freq>] The minimum frequency, in hertz, for the sine sweep

% convolve -h
Usage: convolve input_file impulse_response_file output_file

Recording Setup

The Warehouse Space

13. JavaScript Synthesis and Processing

This section is informative.

The Mozilla project has conducted Experiments to synthesize and process audio directly in JavaScript. This approach is interesting for a certain class of audio processing and they have produced a number of impressive demos. This specification includes a means of synthesizing and processing directly using JavaScript by using a special subtype of AudioNode called ScriptProcessorNode.

Here are some interesting examples where direct JavaScript processing can be useful:

Custom DSP Effects

Unusual and interesting custom audio processing can be done directly in JS. It's also a good test-bed for prototyping new algorithms. This is an extremely rich area.

Educational Applications

JS processing is ideal for illustrating concepts in computer music synthesis and processing, such as showing the de-composition of a square wave into its harmonic components, FM synthesis techniques, etc.

JavaScript Performance

JavaScript has a variety of performance issues so it is not suitable for all types of audio processing. The approach proposed in this document includes the ability to perform computationally intensive aspects of the audio processing (too expensive for JavaScript to compute in real-time) such as multi-source 3D spatialization and convolution in optimized C++ code. Both direct JavaScript processing and C++ optimized code can be combined due to the APIs modular approach.

15. Performance Considerations

15.1. Latency: What it is and Why it's Important

For web applications, the time delay between mouse and keyboard events (keydown, mousedown, etc.) and a sound being heard is important.

This time delay is called latency and is caused by several factors (input device latency, internal buffering latency, DSP processing latency, output device latency, distance of user's ears from speakers, etc.), and is cummulative. The larger this latency is, the less satisfying the user's experience is going to be. In the extreme, it can make musical production or game-play impossible. At moderate levels it can affect timing and give the impression of sounds lagging behind or the game being non-responsive. For musical applications the timing problems affect rhythm. For gaming, the timing problems affect precision of gameplay. For interactive applications, it generally cheapens the users experience much in the same way that very low animation frame-rates do. Depending on the application, a reasonable latency can be from as low as 3-6 milliseconds to 25-50 milliseconds.

15.2. Audio Glitching

Audio glitches are caused by an interruption of the normal continuous audio stream, resulting in loud clicks and pops. It is considered to be a catastrophic failure of a multi-media system and must be avoided. It can be caused by problems with the threads responsible for delivering the audio stream to the hardware, such as scheduling latencies caused by threads not having the proper priority and time-constraints. It can also be caused by the audio DSP trying to do more work than is possible in real-time given the CPU's speed.

15.3. Hardware Scalability

The system should gracefully degrade to allow audio processing under resource constrained conditions without dropping audio frames.

First of all, it should be clear that regardless of the platform, the audio processing load should never be enough to completely lock up the machine. Second, the audio rendering needs to produce a clean, un-interrupted audio stream without audible glitches.

The system should be able to run on a range of hardware, from mobile phones and tablet devices to laptop and desktop computers. But the more limited compute resources on a phone device make it necessary to consider techniques to scale back and reduce the complexity of the audio rendering. For example, voice-dropping algorithms can be implemented to reduce the total number of notes playing at any given time.

Here's a list of some techniques which can be used to limit CPU usage:

15.3.1. CPU monitoring

In order to avoid audio breakup, CPU usage must remain below 100%.

The relative CPU usage can be dynamically measured for each AudioNode (and chains of connected nodes) as a percentage of the rendering time quantum. In a single-threaded implementation, overall CPU usage must remain below 100%. The measured usage may be used internally in the implementation for dynamic adjustments to the rendering. It may also be exposed through a cpuUsage attribute of AudioNode for use by JavaScript.

In cases where the measured CPU usage is near 100% (or whatever threshold is considered too high), then an attempt to add additional AudioNodes into the rendering graph can trigger voice-dropping.

15.3.2. Voice Dropping

Voice-dropping is a technique which limits the number of voices (notes) playing at the same time to keep CPU usage within a reasonable range. There can either be an upper threshold on the total number of voices allowed at any given time, or CPU usage can be dynamically monitored and voices dropped when CPU usage exceeds a threshold. Or a combination of these two techniques can be applied. When CPU usage is monitored for each voice, it can be measured all the way from a source node through any effect processing nodes which apply uniquely to that voice.

When a voice is "dropped", it needs to happen in such a way that it doesn't introduce audible clicks or pops into the rendered audio stream. One way to achieve this is to quickly fade-out the rendered audio for that voice before completely removing it from the rendering graph.

When it is determined that one or more voices must be dropped, there are various strategies for picking which voice(s) to drop out of the total ensemble of voices currently playing. Here are some of the factors which can be used in combination to help with this decision:

• Older voices, which have been playing the longest can be dropped instead of more recent voices.
• Quieter voices, which are contributing less to the overall mix may be dropped instead of louder ones.
• Voices which are consuming relatively more CPU resources may be dropped instead of less "expensive" voices.
• An AudioNode can have a priority attribute to help determine the relative importance of the voices.

15.3.3. Simplification of Effects Processing

Most of the effects described in this document are relatively inexpensive and will likely be able to run even on the slower mobile devices. However, the convolution effect can be configured with a variety of impulse responses, some of which will likely be too heavy for mobile devices. Generally speaking, CPU usage scales with the length of the impulse response and the number of channels it has. Thus, it is reasonable to consider that impulse responses which exceed a certain length will not be allowed to run. The exact limit can be determined based on the speed of the device. Instead of outright rejecting convolution with these long responses, it may be interesting to consider truncating the impulse responses to the maximum allowed length and/or reducing the number of channels of the impulse response.

In addition to the convolution effect. The PannerNode may also be expensive if using the HRTF panning model. For slower devices, a cheaper algorithm such as EQUALPOWER can be used to conserve compute resources.

15.3.4. Sample Rate

For very slow devices, it may be worth considering running the rendering at a lower sample-rate than normal. For example, the sample-rate can be reduced from 44.1KHz to 22.05KHz. This decision must be made when the AudioContext is created, because changing the sample-rate on-the-fly can be difficult to implement and will result in audible glitching when the transition is made.

15.3.5. Pre-flighting

It should be possible to invoke some kind of "pre-flighting" code (through JavaScript) to roughly determine the power of the machine. The JavaScript code can then use this information to scale back any more intensive processing it may normally run on a more powerful machine. Also, the underlying implementation may be able to factor in this information in the voice-dropping algorithm.

TODO: add specification and more detail here

15.3.6. Authoring for different user agents

JavaScript code can use information about user-agent to scale back any more intensive processing it may normally run on a more powerful machine.

15.3.7. Scalability of Direct JavaScript Synthesis / Processing

Any audio DSP / processing code done directly in JavaScript should also be concerned about scalability. To the extent possible, the JavaScript code itself needs to monitor CPU usage and scale back any more ambitious processing when run on less powerful devices. If it's an "all or nothing" type of processing, then user-agent check or pre-flighting should be done to avoid generating an audio stream with audio breakup.

15.4. JavaScript Issues with real-time Processing and Synthesis:

While processing audio in JavaScript, it is extremely challenging to get reliable, glitch-free audio while achieving a reasonably low-latency, especially under heavy processor load.

• JavaScript is very much slower than heavily optimized C++ code and is not able to take advantage of SSE optimizations and multi-threading which is critical for getting good performance on today's processors. Optimized native code can be on the order of twenty times faster for processing FFTs as compared with JavaScript. It is not efficient enough for heavy-duty processing of audio such as convolution and 3D spatialization of large numbers of audio sources.
• setInterval() and XHR handling will steal time from the audio processing. In a reasonably complex game, some JavaScript resources will be needed for game physics and graphics. This creates challenges because audio rendering is deadline driven (to avoid glitches and get low enough latency).
• JavaScript does not run in a real-time processing thread and thus can be pre-empted by many other threads running on the system.
• Garbage Collection (and autorelease pools on Mac OS X) can cause unpredictable delay on a JavaScript thread.
• Multiple JavaScript contexts can be running on the main thread, stealing time from the context doing the processing.
• Other code (other than JavaScript) such as page rendering runs on the main thread.
• Locks can be taken and memory is allocated on the JavaScript thread. This can cause additional thread preemption.

The problems are even more difficult with today's generation of mobile devices which have processors with relatively poor performance and power consumption / battery-life issues.

16. Example Applications

This section is informative.

Please see the demo page for working examples.

Here are some of the types of applications a web audio system should be able to support:

Basic Sound Playback

Simple and low-latency playback of sound effects in response to simple user actions such as mouse click, roll-over, key press.

3D Environments and Games

Electronic Arts has produced an impressive immersive game called Strike Fortress, taking advantage of 3D spatialization and convolution for room simulation.

3D environments with audio are common in games made for desktop applications and game consoles. Imagine a 3D island environment with spatialized audio, seagulls flying overhead, the waves crashing against the shore, the crackling of the fire, the creaking of the bridge, and the rustling of the trees in the wind. The sounds can be positioned naturally as one moves through the scene. Even going underwater, low-pass filters can be tweaked for just the right underwater sound.

Box2D is an interesting open-source library for 2D game physics. It has various implementations, including one based on Canvas 2D. A demo has been created with dynamic sound effects for each of the object collisions, taking into account the velocities vectors and positions to spatialize the sound events, and modulate audio effect parameters such as filter cutoff.

A virtual pool game with multi-sampled sound effects has also been created.

Musical Applications

Many music composition and production applications are possible. Applications requiring tight scheduling of audio events can be implemented and can be both educational and entertaining. Drum machines, digital DJ applications, and even timeline-based digital music production software with some of the features of GarageBand can be written.

Music Visualizers

When combined with WebGL GLSL shaders, realtime analysis data can be presented in entertaining ways. These can be as advanced as any found in iTunes.

Educational Applications

A variety of educational applications can be written, illustrating concepts in music theory and computer music synthesis and processing.

Artistic Audio Exploration

There are many creative possibilites for artistic sonic environments for installation pieces.

17. Security Considerations

This section is informative.

18. Privacy Considerations

This section is informative. When giving various information on available AudioNodes, the Web Audio API potentially exposes information on characteristic features of the client (such as audio hardware sample-rate) to any page that makes use of the AudioNode interface. Additionally, timing information can be collected through the RealtimeAnalyzerNode or ScriptProcessorNode interface. The information could subsequently be used to create a fingerprint of the client.

Currently audio input is not specified in this document, but it will involve gaining access to the client machine's audio input or microphone. This will require asking the user for permission in an appropriate way, probably via the getUserMedia() API.

19. Requirements and Use Cases

Please see Example Applications

B.Acknowledgements

This specification is the collective work of the W3C Audio Working Group.

Members of the Working Group are (at the time of writing, and by alphabetical order):
Adenot, Paul (Mozilla Foundation); Akhgari, Ehsan (Mozilla Foundation); Berkovitz, Joe (Invited Expert); Bossart, Pierre (Intel Corporation); Carlson, Eric (Apple, Inc.); Geelnard, Marcus (Opera Software); Goode, Adam (Google, Inc.); Gregan, Matthew (Mozilla Foundation); Jägenstedt, Philip (Opera Software); Kalliokoski, Jussi (Invited Expert); Lilley, Chris (W3C Staff); Lowis, Chris (Invited Expert. WG co-chair from December 2012 to September 2013, affiliated with British Broadcasting Corporation); Mandyam, Giridhar (Qualcomm Innovation Center, Inc); Noble, Jer (Apple, Inc.); O'Callahan, Robert(Mozilla Foundation); Onumonu, Anthony (British Broadcasting Corporation); Paradis, Matthew (British Broadcasting Corporation); Raman, T.V. (Google, Inc.); Schepers, Doug (W3C/MIT); Shires, Glen (Google, Inc.); Smith, Michael (W3C/Keio); Thereaux, Olivier (British Broadcasting Corporation) – WG Chair; Verdie, Jean-Charles (MStar Semiconductor, Inc.); Wilson, Chris (Google,Inc.); ZERGAOUI, Mohamed (INNOVIMAX)

Former members of the Working Group and contributors to the specification include:
Caceres, Marcos (Invited Expert); Cardoso, Gabriel (INRIA); Chen, Bin (Baidu, Inc.); MacDonald, Alistair (W3C Invited Experts) — WG co-chair from March 2011 to July 2012; Michel, Thierry (W3C/ERCIM); Rogers, Chris (Google, Inc.) – Specification Editor until August 2013; Wei, James (Intel Corporation);

C. Web Audio API Change Log

See changelog.html.