Thanks, marked it as reproduced.
2014-08-21 14:10 GMT+03:00 Floh <[email protected]>: > 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]>: >> >> 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. > -- 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.
