- From: Marcus Geelnard <mage@opera.com>
- Date: Fri, 05 Jul 2013 13:01:53 +0200
- To: Chris Rogers <crogers@google.com>
- CC: Robert O'Callahan <robert@ocallahan.org>, Joseph Berkovitz <joe@noteflight.com>, "public-audio@w3.org" <public-audio@w3.org>, Dave Herman <dherman@ccs.neu.edu>, "Mark S. Miller" <erights@google.com>
Just for reference, I created a small test application that behaves
differently in Chromium and in Firefox:
http://people.opera.com/mage/test/racyaudiobuffers.html
The test app will behave oddly if the buffer data is shared between the
audio thread and the JS context, which it is in Chromium. In this case,
I tried to mimic the result of a "programming error" that makes the
audio buffer array be unintentionally re-used in another place (could be
done intentionally too, of course).
I know that this particular application is a bit unrealistic, but
nevertheless it shows one important thing: Something that seems to work
as expected in one browser (in this case Firefox) seems to be completely
broken in another browser (in this case Chromium). You could also come
up with examples that show the opposite behavior ("works" in Chromium
but not in Firefox).
Now, regardless if we could live with a racy API or not (I strongly
object to it), we still have the issue that the spec is not at all clear
on how to treat arrays that have been passed to the API (as a Web
developer I would expect them to be copied, e.g. in the same way as
WebGL texImage2D). I really think that we need to specify this!
...and, if we go down the road of specifying racy behavior, I'm pretty
sure that we'll make life a lot harder not only for Web developers but
also for implementors wishing to utilize certain optimization techniques
etc.
/Marcus
--
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software
Received on Friday, 5 July 2013 11:03:02 UTC