1,295
edits
User:Roc/AudioBufferProposal: Difference between revisions
Jump to navigation
Jump to search
→Advocacy
No edit summary |
|||
| Line 67: | Line 67: | ||
Webkit and Blink developers have indicated that they'll keep around the webkit-prefixed <tt>AudioContext</tt> API for a long time. This proposal provides substantial compatibility with that API, which has value for authors and browser implementers, especially given the amount of content already written to that API. | Webkit and Blink developers have indicated that they'll keep around the webkit-prefixed <tt>AudioContext</tt> API for a long time. This proposal provides substantial compatibility with that API, which has value for authors and browser implementers, especially given the amount of content already written to that API. | ||
I argue that this proposal is no more complicated than other proposals. Compared to Jer's proposal, this proposal has less API surface, and less complexity for Web developers who don't need to read or write channel data after an <tt>AudioBuffer</tt> has been used (since they don't have to think about node liveness) | I argue that this proposal is no more complicated than other proposals. Compared to Jer's proposal, this proposal has less API surface, and less complexity for Web developers who don't need to read or write channel data after an <tt>AudioBuffer</tt> has been used, or who are not very concerned about performance (since they don't have to think about node liveness). For developers who are very concerned about performance, and who want to modify channel data between uses of an <tt>AudioBuffer</tt>, the proposals are very similar; they'll have to think about node liveness. (Jer's proposal throws an exception when writing data to an in-use <tt>AudioBuffer</tt>, which is informative for Web authors who want to avoid copies; but with my proposal we can provide a similar alert through Web developer tools.) My proposal may be more complicated for implementers --- or not, since Jer's proposal requires implementations to track precisely when an <tt>AudioBuffer</tt> is associated with a live <tt>AudioNode</tt>, and this proposal does not. | ||
Compared to the "freely share memory" proposal, assuming that proposal is fully fleshed out to define what authors and implementations are allowed to do, this proposal is almost the same for Web developers. The only extra complexity for Web developers is that they should call <tt>copyChannelDataTo</tt> to read channel contents instead of reading from <tt>getChannelData</tt> arrays, if an <tt>AudioBuffer</tt> could be in use. (Web developers writing to <tt>getChannelData</tt> arrays should ensure that the <tt>AudioBuffer</tt> is not in use, under both proposals.) For implementers, the "freely share memory" proposal is probably less complex, although the "<tt>ArrayBuffer</tt> is neutered while we're playing it" problem must be solved trickily while this proposal solves it easily. (Of course, implementers who don't wish to rely on undefined C++ behavior, or who wish to use non-shared-memory hardware, will have a hard time with the "freely share memory" proposal (or be forced to make copies at inopportune times).) | Compared to the "freely share memory" proposal, assuming that proposal is fully fleshed out to define what authors and implementations are allowed to do, this proposal is almost the same for Web developers. The only extra complexity for Web developers is that they should call <tt>copyChannelDataTo</tt> to read channel contents instead of reading from <tt>getChannelData</tt> arrays, if an <tt>AudioBuffer</tt> could be in use. (Web developers writing to <tt>getChannelData</tt> arrays should ensure that the <tt>AudioBuffer</tt> is not in use, under both proposals.) For implementers, the "freely share memory" proposal is probably less complex, although the "<tt>ArrayBuffer</tt> is neutered while we're playing it" problem must be solved trickily while this proposal solves it easily. (Of course, implementers who don't wish to rely on undefined C++ behavior, or who wish to use non-shared-memory hardware, will have a hard time with the "freely share memory" proposal (or be forced to make copies at inopportune times).) | ||