RE: Continuous playback of javascript synthesized consecutive audio buffers causes audio artifacts when no buffer starving occurs.

Not knowing all the issues, but isn't this what SMIL was for? It certainly
works well in SVG in all places but one (and a few little places where
browsers have been recalcitrant to fix bugs). Lots of the SVG animations
move much more smoothly in most browsers than the "equivalent"
implementation with script. 

 

cheers

David

 

From: Patrick Martin [mailto:patrick.martin.r@gmail.com] 
Sent: Tuesday, October 29, 2013 9:18 PM
To: <public-audio@w3.org>
Subject: Fwd: Continuous playback of javascript synthesized consecutive
audio buffers causes audio artifacts when no buffer starving occurs.

 

 

---------- Forwarded message ----------
From: Patrick Martin <patrick.martin.r@gmail.com>
Date: Tue, Oct 29, 2013 at 6:17 PM
Subject: Re: Continuous playback of javascript synthesized consecutive audio
buffers causes audio artifacts when no buffer starving occurs.
To: "Srikumar K. S." <srikumarks@gmail.com>



The issue is that the current implementation can't do it accurately as
scheduling always includes some delay from the scheduling javascript code.
ie if you schedule a buffer to playback in x seconds you're actually
scheduling it in x seconds + execution time of the javascript (which may
even be interuppted). the whole idea behind a queue is that as long as you
have buffers in the queue there will be no delay in playback/artifacts due
to buffer switching.

 

On Tue, Oct 29, 2013 at 2:55 PM, Srikumar K. S. <srikumarks@gmail.com>
wrote:

Ah I see. 

 

We've seen some discussion regarding the modifiability of buffers that have 

been assigned to source nodes (i.e. the "race condition wars"). This
jsfiddle

(http://jsfiddle.net/gy5AU/) shows code that modifies a single 22050Hz

buffer periodically to generate a glitch-free (up to setTimeout's jitter) 

440Hz sine tone.

 

This produces a clean tone on my machine unlike the original beep.html

test case ... but should this work at all?

 

-Kumar

 

On 30 Oct, 2013, at 1:38 am, Joseph Berkovitz <joe@noteflight.com> wrote:





If I'm not mistaken I think the original issue here was sequencing audio
buffers whose playback rate was not equal to the AC sample rate, and were
thus being up- or down-sampled for playback. In this case one gets aliasing
problems at the splice point between successive buffers, and the spec is
silent about this sort of thing. These aliasing issues do not arise when the
playback rate and the AC sample rate are equal.

 

I don't think the buffer queue model below would address this (although it's
very useful in its own right).

 

On Oct 29, 2013, at 3:18 PM, Srikumar K. S. <srikumarks@gmail.com> wrote:





It would allow for pre-synthesized audio playback in a glitch free manner.

I'm not sure whether this is to address an implementation bug or a spec
shortcoming. The concept of a buffer queue can already be expressed using
the AudioBufferSourceNode. Whether it works without glitches in current
implementations is likely not a spec shortcoming .. unless it is impossible
to create such an implementation, which I don't think is the case.

 

For instance, see the buffer_queue model at
https://github.com/srikumarks/steller/blob/master/src/models/buffer_queue.js
. The example code there asks for a function to be called when the queue
runs low, but it can sequence buffers passed to the "enqueue" method. 

 

Reproducing the 440Hz sine tone example here -

 

   var ac = new AudioContext;
   var sh = new org.anclab.steller.Scheduler(ac);
   var q = sh.models.buffer_queue();
   q.connect(ac.destination);
   q.on('low', function () {
       var phase = 0.0, dphase = 2.0 * Math.PI * 440.0 / 44100.0;
       return function (lowEvent, q) {
           var audioBuffer = q.createBuffer(1, 1024);
           var chan = audioBuffer.getChannelData(0);
           var i;
           for (i = 0; i < 1024; ++i) {
               chan[i] = 0.2 * Math.sin(phase);
               phase += dphase;
           }
           q.enqueue(audioBuffer);
       };
   }());
   q.start(ac.currentTime);

 

-Kumar

 

On 30 Oct, 2013, at 12:25 am, Patrick Martin <patrick.martin.r@gmail.com>
wrote:





It would allow for pre-synthesized audio playback in a glitch free manner.

On Oct 20, 2013 10:06 PM, "Robert O'Callahan" <robert@ocallahan.org> wrote:

On Mon, Oct 21, 2013 at 6:35 AM, Srikumar Karaikudi Subramanian
<srikumarks@gmail.com> wrote:

What advantage might such an AudioBufferSequenceNode have over a
ScriptProcessorNode with a queue processing render function?

 

It would probably have the advantage of not being susceptible to small
amounts of main-thread jank.




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  

 

 

.            .       .    .  . ...Joe

 

Joe Berkovitz

President

 

Noteflight LLC

Boston, Mass.

phone: +1 978 314 6271 <tel:%2B1%20978%20314%206271> 

www.noteflight.com <http://www.noteflight.com/> 

"Your music, everywhere"