Re: How to play back synthesized 22kHz audio in a glitch-free manner?

Could one simply define a ResamplerNode/PlaybackRateAdjustmentNode? Then,
in cases where you want to stitch together smaller buffers and adjust the
playback rate of all of them, you give them all the resampler node as a
shared destination.

This would allow removing the .playbackRate attribute of
AudioBufferSourceNode entirely, and it would probably be more generally
useful anyway - for example, resampling ScriptProcessorNode outputs
entirely, adjusting the playback rate of audio from an <audio> element,
etc. I'd argue that such a change would have a good symmetry with the
removal of .gain and provide benefits for developers.

Separate from this, though, we still ultimately need a way to schedule
buffers in a sample-precise manner - whether it's changes to the definition
of start()/etc in order to enable sample-precise start times, or a
startImmediatelyAfter method. But splitting playback rate adjustment out
would at least let people realistically use ScriptProcessorNode in these
scenarios, which would be great!

-kg


On Mon, Jun 17, 2013 at 2:36 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Jun 18, 2013 at 7:25 AM, Jukka Jylänki <jujjyl@gmail.com> wrote:
>
>> If the Web Audio API had an explicit support for buffer
>> queueing/stitching with AudioBufferSourceNodes, and the user could give
>> that contract to the Web Audio impl with the 'startImmediatelyAfter'
>> function, then the implementation could perform audio resampling on the
>> stream as a whole, and not to discontinuous source nodes individually.
>>
>
> Only if they have the same set of destinations. I suppose that could be
> done but it's not trivial. Then again, it would solve use cases for which
> ScriptProcessorNode is not a very good fit.
>
> Rob
> --
> Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le
> atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
> stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm
> aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt
> wyeonut thoo mken.o w
>