Re: Proposal for fixing race conditions

> Are you suggesting the editor would play the audio data while simultaneously allowing the user to edit it?

I was not suggesting that and merely pointing out a case where "copy on assignment to source.buffer" would not work as a solution to race conditions due to its performance impact.

> If so, that's a good example of how race conditions are likely to lead to bizarre and unpredictable behavior.

Yes indeed. But the "edit live" behaviour is inherently racy, so if the race problems are solved, I'd expect that a naive implementation of such a "feature" should not work. For such a racy feature, devs should be forced to design a solution by themselves instead of naively expecting the system to "just work" by writing racy code. That way, the behaviour would be in the devs' hands and not at the mercy of the implementation ... for which consistency they'll thank the designers of the API ... eventually :)

> If not, then if my proposal is adopted, a browser could handle this case efficiently. When a stop() call means the audio thread no longer needs access to a buffer, the memory can be returned to the AudioBufferSourceNode so that the next call to getChannelData() can use that memory again instead of copying it.

This might work for this case where one would stop playback before starting it again, but it won't work in general where we need multiple instances of one sound to be played. In that case, reference counting upon start()/stop() would perhaps be needed to determine when to release the buffer back to JS. I think all this is crazy complex for a developer to understand and use correctly .. and devs need special instruction for stuff which is not explicit in the code.

For the use case of loading a bunch of sounds and triggering them with effects chains, a solution with pure immutable buffers would be ideal. For anything needing complex mutation, it would be possible to design data structures in JS that simulate mutation and use them in a script node. The script node would bring its own problems (delay, large buffers), but that may still be workable for this DAW "edit live" scenario.

-Kumar


On 17 Jul, 2013, at 8:12 AM, "Robert O'Callahan" <robert@ocallahan.org> wrote:

> On Wed, Jul 17, 2013 at 2:24 PM, Srikumar Karaikudi Subramanian <srikumarks@gmail.com> wrote:
>> Your hypothetical test case merely demonstrates the difference; my point is that it is silly to optimize for imaginary edge cases at the cost of real-world use cases where developers will get unexpected results due to leaving race conditions in this API. I should also note that it has come up in past discussions that we could always introduce new no-copy APIs that don't contain races, if the cost of memcpy is so severe.
> 
> It is not inconceivable to make an audio editor which plays an audio file from a specific sample onwards by assigning the buffer to an AudioBufferSourceNode and using start(t,offset,duration) ... possibly followed by effects. Large files (even 5mins?) would be unusable with such an editor if a copy were involved and clients/devs will be forced to do crazy optimizations just to get it to work.
> 
> Are you suggesting the editor would play the audio data while simultaneously allowing the user to edit it?
> 
> If so, that's a good example of how race conditions are likely to lead to bizarre and unpredictable behavior.
> 
> If not, then if my proposal is adopted, a browser could handle this case efficiently. When a stop() call means the audio thread no longer needs access to a buffer, the memory can be returned to the AudioBufferSourceNode so that the next call to getChannelData() can use that memory again instead of copying it.
> 
> 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