LÖVE

Any reason love.audio.newSource has to duplicate the buffer into internal storage? It would've been a lot easier to playback procedurally generated samples (especially large ones) if it could play the original soundData modified in place. As it is now I have to continuously call love.audio.newSource every time write buffer accumulates substantial length of samples to play. Having a callback triggered when read header reaches end of buffer requiring more streaming data would also be nice.

It's how OpenAL works.

In OpenAL there are multiple buffers which are played back in a queue sequence, there's nothing preventing feeding it new data continuously.

Which is exactly how Decoders work, though it is fed in a background thread, so just calling a lua callback from that isn't really an option.

And besides, there's a realtime alternative already.

zorg wrote:And besides, there's a realtime alternative already.

Thanks! It's not ideal - I'd really prefer to use LOVE's own implements to do it to injecting into its runtime like this - but it works and it's not an ugly mess of dirty hacks.

bartbes wrote:Which is exactly how Decoders work, though it is fed in a background thread, so just calling a lua callback from that isn't really an option.

I haven't been able to find a way to produce an object that would pass for a decoder, so that I could use it to feed encompassing audio source sound data.

raidho36 wrote:

zorg wrote:And besides, there's a realtime alternative already.

Thanks! It's not ideal - I'd really prefer to use LOVE's own implements to do it to injecting into its runtime like this - but it works and it's not an ugly mess of dirty hacks.

bartbes wrote:Which is exactly how Decoders work, though it is fed in a background thread, so just calling a lua callback from that isn't really an option.

I haven't been able to find a way to produce an object that would pass for a decoder, so that I could use it to feed encompassing audio source sound data.

It was talked about before, on irc mostly, but i did mention that i'd be inclined to volunteer to try and think out how löve's audio API could be improved, to include realtime data queueing onto the soundcard through OpenAL; that said, i'd rather finish my example project(s) first to show what's possible.

As far as I'm concerned, all you have to do is expose QueueBuffers equivalent for the sound source class. Including underlying library's basic functionality in your wrapper isn't rocket science.

raidho36 wrote:isn't rocket science.

Pull requests for LÖVE's source are welcome! We do want to have streaming Sources with queue-able data, but no one has implemented it yet.

As I said elsewhere, I have problem navigating the source. Which files would be the relevant ones?