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.
