W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

[Bug 22723] New: OfflineAudioContext and ScriptProcessorNodes

From: <bugzilla@jessica.w3.org>
Date: Thu, 18 Jul 2013 14:02:52 +0000
To: public-audio@w3.org
Message-ID: <bug-22723-5429@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723

            Bug ID: 22723
           Summary: OfflineAudioContext and ScriptProcessorNodes
    Classification: Unclassified
           Product: AudioWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Audio API
          Assignee: crogers@google.com
          Reporter: olivier.thereaux@bbc.co.uk
        QA Contact: public-audio@w3.org

E-mail Thread:
http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg105

Kumar Wrote:
Q: Can script processor nodes be expected to run 
synchronously during offline rendering?

By that I mean will native components wait for 
a script node to complete its task before proceeding
to the next block of sample frames? Though it would
be ridiculous if they are not, the spec isn't clear 
on this.

When using the realtime context, the audio thread
is not expected to wait for compute intensive 
script nodes and consequently the script nodes
operate with a delay. This delay is unnecessary 
when rendering using the offline context and it
would be ok for the rendering thread to wait for 
the JS code before continuing.

Ensuring this has another benefit - that of providing
a mechanism by which we can use a script node as a
periodic callback timer to instantiate native nodes
just in time when rendering long compositions.


Chris Rogers replied:

Yes, this is how it should work.  
Currently, this is a limitation in the WebKit and Blink implementations.



TODO: edit the spec accordingly.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 18 July 2013 14:02:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:10 UTC