On Aug 8, 2013, at 6:16 AM, Marcus Geelnard <mage@opera.com> wrote:
> I strongly believe that the most critical part of the current API that could potentially block such future directions is the requirement that the audio data buffers must be shared between the audio engine and the JS engine. It might seem to be an optimal solution (performance wise) right now, but it literally kills many attempts to move audio processing off-CPU (e.g. try to imagine the limitations imposed on a hardware accelerated 3D graphics processor if it had to be able to observe data mutations made by the CPU in shared RAM).
To be accurate, I don't think the proponents of retaining the current API approach have asked that sharing memory be a requirement -- only that it should be permitted, and is desirable under "safe" timing scenarios, but not to be relied upon in "risky" ones. It would, I think, be possible to implement something like ROC's proposal minus the neutering and still conform to the current API, while getting rid of potential shared-memory side effects.
This is not an argument per se for retaining the current API approach, just an attempt to better characterize the "leave it as is" position. I personally favor legislating away the shared-memory effects via some variant of the alternative proposals on the table and moving on to other matters.
. . . . . ...Joe
Joe Berkovitz
President
Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"