On Fri, Sep 20, 2013 at 7:09 PM, Jussi Kalliokoski <notifications@github.com > wrote: > What things? > > Gecko never has the main thread wait on the audio thread. > > How have you implemented getChannelData then? As a quick shot at it the > only ways I can think of to do this: > > - The audio data of AudioBuffers is stored on the main thread and > copied to the audio thread whenever AudioBufferSourceNode#buffer is > set. I suppose this would be the most viable option for JS, but terribly > inefficient. > - Shared memory? Probably not, since that would go against your > proposal. :) > > > - COW? This seems like the most likely option to me, but this can't be > done in JS. > > https://wiki.mozilla.org/User:Roc/AudioBufferProposal#Implementation_Sketchis basically what we do. While we're in the arrays-neutered state, the buffer data is stored in an ImmutableBufferSet which is readable by both the main thread and the audio thread at any time. This is innocuous since, like it says on the label, that data is immutable. When we talk about shared memory being a problem, it's only a problem when one thread can write to the memory while another thread reads it. Immutable data in shared memory is all good. 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 Friday, 20 September 2013 07:18:19 UTC