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]>: > 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]. > 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.
