Link to ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1056657
I'll keep the sample around on a separate page so it won't be overwritten by engine updates here: http://floooh.github.io/oryol-sticky-tests/SynthTest.html Cheers, -Floh. Am Mittwoch, 20. August 2014 18:46:17 UTC+2 schrieb jj: > > I can reproduce this on Windows. In Chrome, the wave sounds perfect from > the start, and in current Firefox Nightly, the wave takes about half a > second to stabilize, and after that I get periodic short glitches in it. > There is one issue in Firefox I'm aware about regarding this: > https://bugzilla.mozilla.org/show_bug.cgi?id=848954 . Since it works in > Chrome but not in Firefox, I would directly go ahead an open up a new one > in Firefox bugzilla for that. > > > 2014-08-20 16:47 GMT+03:00 Floh <[email protected] <javascript:>>: > >> Hi, >> >> I've started to play around with OpenAL a bit, goal is to create a simple >> audio subsystem which can play old-school / chiptune style sound-effects >> without pre-baked wav data (may be 'rendering' the audio data on the GPU, >> I'll try both approaches, JS and GPU and see which one makes more sense). >> >> So... I hacked together a simple buffer streamer, at the moment this >> simply fills 4 kByte OpenAL buffers with a square wave, enqueues them for >> playback and recycles them after they've played. In the end these buffers >> will probably even have to be smaller to keep latency low (but there's a >> conflict with trying to avoid starving the buffer queue if the next buffer >> can't be enqueued in time, unfortunately I can't discard audio buffers >> which are already enqueued but not yet played in OpenAL). >> >> Even with this simple demo (here: >> http://floooh.github.io/oryol/SynthTest.html) I'm seeing different >> behaviour between Chrome and Firefox: Chrome plays the sound stable right >> from the start, while Firefox (at least on my OSX MBP, but I also have >> reports from others) needs a second or two for 'warmup' during which time >> there are artefacts. The buffer queue never seems to run dry though, and >> the buffer size of 4kByte at 2 bytes per sample should be good for about >> 0.1 seconds at 22kHz playback rate that I'm currently using (OpenAL should >> set the audio source to 'stopped' state after playing the last enqueued >> buffer, which doesn't seem to happen -> in this case there should be more >> then one line of 'alBufferStreamer: starting playback'). >> >> Is this a known problem in Firefox's WebAudio implementation or the >> emscripten OpenAL wrapper? Should I do something differently when enqueuing >> the buffers? Should I write tickets for this? :) >> >> Cheers! >> -Floh. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
