- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Dec 2012 18:26:55 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17335 --- Comment #12 from Chris Rogers <crogers@google.com> --- Here's my take: AudioParam already has several ways of being controlled: 1) linear and exponential ramps: these are *very* well established ways of controlling parameters going back decades in computer music systems and synth design. Furthermore, these can be a-rate, so much smoother than systems which work exclusively using k-rate. 2) arbitrary curves: These are mostly useful as slowly varying curves, but can be oversampled to a very high degree (2x, 4x, 8x) by providing a Float32Array which is far longer than the duration of the curve. I don't think we should be worried about memory performance here since these will still generally be much smaller than the audio assets themselves. This oversampling can help to a great degree to band-limit the signal. 3) control via audio-rate signals: These signals can be band-limited to the extent that source node, and the processing nodes use band-limited approaches. Especially with (3) we have a pretty rich possibility of controlling the parameters, including ways which are concerned about band-limited signals. This does bring up other areas of the API which need to be concerned with aliasing: AudioBufferSourceNode: currently its interpolation method is unspecified. WebKit uses linear interpolation, but cubic, and higher order methods could be specified using an attribute. OscillatorNode: once again the quality could be controlled via attribute. WebKit currently implements a fairly high-quality interpolation here WaveShaperNode: there are two aspects of interest here: 1) How is the .curve attribute sampled? Currently the spec defines this as "drop sample" interpolation and not even linear, but we should consider the option of linear. I'm concerned about this one because I notice people are using the WaveShaperNode for distortion with relatively small curves (such as 8192 in tuna.js) which will end up not only shaping the signal, but adding a bit-crushing/bit-decimation effect, which may or may not be the effect wanted) 2) Is the wave-shaping curve applied at the AudioContext sample-rate, or is the signal first up-sampled to a higher sample-rate to avoid aliasing?? The option to have band-limited wave-shaping will become more and more important with the advent of applications like guitar amp simulations. Aliasing can seriously affect the quality of the distortion sound. We know people are interested in these kind of applications, since they're already showing up: (Stuart Memo's work, tuna.js, and http://dashersw.github.com/pedalboard.js/demo/) -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 11 December 2012 18:27:01 UTC