Hi Grant, We were discussing your email in the telecon yesterday. You are bringing up some very interesting points, but it would be great if we could get further clarification. Any chance you could d31337ify your explanation for us? :) Obviously we should keep discussing this on the mailing list here, but I think it would be very beneficial for you, Jussi, Chris R. and ROC to discuss this issue during the telecon on Monday. Grant, what I get from your email is that having the sample-rate locked in by the Audio API makes it very difficult to deliver the kind of performance you need for the applications you are developing. Is this correct? Could you explain a little more about what exactly you are doing, and how you are doing it? Many thanks, Alistair On Sat, Mar 17, 2012 at 5:26 AM, Grant Galitz <grantgalitz@gmail.com> wrote: > In the rewrite of the PAPU emulation core for LLE type emulation of the JS > GBC emulator, I've bumped the sample rate to 4194304 (yeah, as in over 4 > megahertz). The older core used to not have a problem with resampling in > javascript itself as the previous core was based around being sample rate > arbitrary (though it had to be set high enough to prevent most games from > having artifacts). Now that resampling has to be done by the browser, any > word on that? > > https://github.com/grantgalitz/XAudioJS/blob/master/resampler.js is the > script being used to resample directly in javascript. > > FYI, the mozilla audio data api actually takes this sample rate and > resamples from there, it's just google chrome's web audio api that is > lacking in a core necessity. :D > -- Alistair MacDonald SignedOn, Inc - W3C Audio WG Boston, MA, (707) 701-3730 al@signedon.com - http://signedon.com
Received on Tuesday, 20 March 2012 15:13:00 UTC