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

Re: "ScriptProcessorNode is Unfit For Purpose" issue

From: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
Date: Fri, 26 Jul 2013 14:49:48 +0000
To: "<robert@ocallahan.org>" <robert@ocallahan.org>
CC: Alex Russell <slightlyoff@google.com>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <D8BB0D3C-763B-46E9-9E95-98C7BBF89404@bbc.co.uk>

On 26 Jul 2013, at 00:50, Robert O'Callahan <robert@ocallahan.org> wrote:

> I think the general idea of adding APIs for ScriptProcessorNode with Workers is uncontroversial. (Personally I'd recommend not creating a new Worker class and instead just dispatching new messages to existing workers, but we can debate that later.) However I think there's been a feeling we should defer that to some level 2 spec.
>
> Main-thread ScriptProcessorNodes are useful. If you only want to monitor produced audio and you're not latency-sensitive, they work perfectly well. If you're generating audio they can still work quite well if the UA implements them carefully. For example, in Gecko we adaptively increase buffering to mostly eliminate glitching. The reality is that a lot of the things you might want to do when generating audio data (e.g. implement a game emulator) can only be done on the main thread today, so for many applications audio-generating Workers would not be immediately useful.

Indeed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--
Olivier


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
Received on Friday, 26 July 2013 14:50:28 UTC

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