This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Reference from mailing list: post: http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0395.html author: Russell McClellan <russell@motu.com> "[OfflineAudioContext] really should provide some way to receive data block-by-block rather than in a single "oncomplete" callback. Otherwise, the memory footprint grows quite quickly with the rendering time. I don't think this would a major burden to implementors, and it would make the API tremendously more useful. Currently it's just not feasible to mix down even a minute or so. If this is ever going to be used for musical applications, this has to change." Chris Rogers stated in teleconference 14 Mar 2013 that it is in fact feasible to mix down typical track lengths of several minutes with the single oncomplete call. A discussion of block size suggested that any breaking of audio rendering into chunks should be fairly large to avoid overhead of switching threads and passing data.
> Chris Rogers stated in teleconference 14 Mar 2013 that it is in fact feasible to mix down typical track lengths of several minutes with the single oncomplete call. One thing is that situations where you might expect to get long renderings (several hours) are studio software and scientific applications. Neither are typically run on devices with little memory, and if you think that uncompressed stereo CD quality gives you 80min @ 700MB, the problem may or may not be very serious. Either way, I think that the offline context should have an error callback as well, and if you run out of memory during the rendering the callback should be invoked. However, to speculate a bit, another approach for handling long renderings is to direct the output to a MediaStreamRecorder which will hopefully in the future allow extracting compressed formats as well. This would allow the UA take care of the render/compress cycle and block sizes, and the API would just hand the developer a readily rendered blob to use however needed. I'm not quite up to date on MediaStreamRecorder though, perhaps Roc knows more about whether this is feasible or not.
(In reply to comment #1) > However, to speculate a bit, another approach for handling long renderings > is to direct the output to a MediaStreamRecorder which will hopefully in the > future allow extracting compressed formats as well. The whole point of MediaStreamRecorder is to support compression so I think that'll be supported as soon as MediaStreamRecorder is implemented. > This would allow the UA > take care of the render/compress cycle and block sizes, and the API would > just hand the developer a readily rendered blob to use however needed. I'm > not quite up to date on MediaStreamRecorder though, perhaps Roc knows more > about whether this is feasible or not. It's feasible but we need to specify how MediaStreamRecorder and OfflineAudioContext interact since currently MediaStreams are real-time-only. I think it's pretty important to have some mechanism whereby OfflineAudioContext can deliver data incrementally.
Web Audio API issues have been migrated to Github. See https://github.com/WebAudio/web-audio-api/issues
Closing. See https://github.com/WebAudio/web-audio-api/issues for up to date list of issues for the Web Audio API.