SoundQueues

[raidho36]

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.

[slime]

It's how OpenAL works.

[raidho36]

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

[bartbes]

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.

[zorg]

And besides, there's a realtime alternative already.

[raidho36]

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.

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.

[zorg]

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.

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.

[raidho36]

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.

[slime]

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.

[raidho36]

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