What advantage might such an AudioBufferSequenceNode have over a ScriptProcessorNode with a queue processing render function? -Kumar On 19 Oct, 2013, at 8:48 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote: > One way we've talked about solving this is to allow you to construct an AudioContext with a specified sample rate. Then you should be able to use AudioBufferSourceNode.start(t) to schedule buffers back-to-back and get good results. > > If you want to have different buffer sequences with different sample rates and mix the results somehow, that gets tricky. You could theoretically do it by hooking together multiple AudioContexts using MediaStreamAudioSource/DestinationNode. > > It might be better to have a new node type, say AudioBufferSequenceNode, which has a fixed but selectable sample rate and lets you explicitly queue buffers for playback. > > 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
Received on Monday, 21 October 2013 04:35:33 UTC