On Jul 17, 2013, at 8:00 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote: > Maybe I'm missing something, but as far as I know, nobody has made such a proposal, so I'm not sure why we're discussing that. It's important to illustrate the significant costs of these proposals whenever they would require additional memcopys. Perhaps the "worst case spec" scenario was a poor illustration, however. My apologies for derailing the conversation. > As Robert pointed out earlier in this thread, the only cases where the current proposals suggest blind copying are AudioParam.setValueCurveAtTime and WaveShaperNode.curve. The basic reason is that those APIs deal with Float32Arrays and not AudioBuffers, so neither Robert's or Jer's proposals for AudioBuffers will directly address that, unless we're willing to break those APIs and make them use AudioBuffers. Well, if we're breaking things anyway... ;-) > That is also a crucial point which I believe is getting lost in this conversation. These performance concerns are only about how efficiently we can run legacy code while maintaining the current API. If we're willing to break API backwards compatibility by making AudioBuffers immutable for example, and avoid using Float32Arrays anywhere except as an argument to the AudioBuffer constructor, then we'll avoid all of the memcpy costs in the normal usage of the API, except when creating an AudioBuffer. So, it's not like that our two alternatives are not fixing the race conditions at all, or memcpy data all the time on every call into the API. Generally that is true, but "except when creating an AudioBuffer" is a very large caveat. There are some use cases (e.g., generated audio playback) which would hit this edge case. -Jer
Received on Wednesday, 17 July 2013 15:59:19 UTC