- From: Dmitry Lomov <dslomov@google.com>
- Date: Thu, 1 Mar 2012 13:58:02 -0800
- To: robert@ocallahan.org
- Cc: Alistair MacDonald <al@signedon.com>, Chris Rogers <crogers@google.com>, public-audio@w3.org
- Message-ID: <CAObu7DERSm9b_yayJ8we1v3i5hqm_t87sv3sDj_r+Ri=ry6=uw@mail.gmail.com>
On Wed, Feb 29, 2012 at 2:52 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Wed, Feb 22, 2012 at 5:34 AM, Alistair MacDonald <al@signedon.com>wrote: > >> ROC, I noticed I could not get access to audio data with the MediaStreams >> API without using a Worker thread (using your recent builds and demos). >> Jussi said he believes this the case too. Could you confirm this? If so - >> is this by-design? I am trying to figure out whether there is a technical >> suggestion of dropping JavaScript Processing of audio data from the >> main-thread all-together, or is this was merely a matter of tackling the >> Worker code as a priority. > > > Main-thread access to audio data may not be necessary, since it's easy for > a Worker to use postMessage to communicate to/from the main thread. For > example, see > http://people.mozilla.org/~roc/stream-demos/analyzing-audio.html > http://people.mozilla.org/~roc/stream-demos/sample-fetcher.js > The worker code is literally > self.onprocessmedia = function(event) { > var msg = { > channels: event.audioChannels, rate: event.audioSampleRate, > samples: event.inputs.length > 0 ? event.inputs[0].audioSamples : null, > }; > postMessage(msg); > }; > If the demo needed any processing at all of the data, performance would > improve by doing that processing in the worker so you'd be winning by > having the worker involved. > > There may be scenarios where direct main-thread audio data processing is a > significant win over Worker+postMessage, e.g. due to reduced overhead > and/or convenience. I don't know yet. If those scenarios are non-existent > or extremely rare, then *not* having main-thread audio data processing APIs > is simpler and encourages authors to do the right thing by using Workers as > much as possible. > > So right now I do not know whether having API support for main-thread > audio data processing is a good idea. > FWIW, I concur. Main-thread audio-processing, due to a real-time nature of the latter, would introduce contention with a primary purpose of the main thread (which is rednder as fast as possible and react to user input quickly). > > Rob > -- > “You have heard that it was said, ‘Love your neighbor and hate your > enemy.’ But I tell you, love your enemies and pray for those who persecute > you, that you may be children of your Father in heaven. ... If you love > those who love you, what reward will you get? Are not even the tax > collectors doing that? And if you greet only your own people, what are you > doing more than others?" [Matthew 5:43-47] > >
Received on Thursday, 1 March 2012 21:58:31 UTC