Configurable sample rate conversion quality

[bjornm]

I would like a way to control the sample rate conversion quality applied when the AudioContext.sampleRate does not match the underlying output device. The quality could be described as e.g. low latency, low cpu (linear interpolation) or high quality (FIR convolution). This should preferably be configurable at runtime to adapt to host performance. Example:

enum SampleRateConversionQuality {
"fastest", // no interpolation at all
"fast", // linear interpolation
"normal", // fir convolution
..
}

audioContext.sampleRateConversionQuality = ...;

SampleRateConversionQuality would also make sense for AudioBufferSourceNodes with playbackRate != 1 and possibly for WaveShapers with upsampling. Maybe some other nodes as well?

I'm unsure as to whether these settings make sense in all situations. E.g. would it make sense to use no interpolation at all for an upsampled waveshaper when the whole purpose of upsampling is to increase quality?

[cwilso]

This is subjugated to #300.

[mdjp]

Makes sense as audio context contructor property. Will keep for v.next.

[padenot]

Virtual F2F:

• Measuring the cost of high-quality resampling needs to be done before allowing to change this from being UA specific

[padenot]

TPAC 2020:

• Being able to change the resampling quality of the AudioContext and also per node seem very useful.
• The former because the latency added by a resampler can be significant (compared to, for example, the latency floor of an AudioContext, which is 128 frames for now)
• The latter because sometimes you know your audio assets don't really deserve super high quality resampling and you'd rather spend the CPU elsewhere (say, a game with a gunshot asset, you'd rather spend the cpu on physics), or you want to save CPU cycles if the machine cannot sustain a high load (degraded mode that still works well vs. constant underruns)
• It seems like the ability to set an AudioBufferSourceNode and AudioContext resampling quality/cost/latency trade-off at construction would be enough

[rtoy]

Virtual F2F 2021: Everything from https://github.com/WebAudio/web-audio-api-v2/issues/25#issuecomment-713708269 still stands, but we'll probably only do this for an AudioContext and AudioBufferSourceNode.