newSoundData performance - Default decoder buffer size

Issue #615 wontfix
created an issue


someLargeNumber = 8^8
decoder = love.sound.newDecoder('sound.ogg', someLargeNumber)
sounddata = love.sound.newSoundData(decoder)

is faster than this:

decoder = love.sound.newDecoder('sound.ogg')
sounddata = love.sound.newSoundData(decoder)

at least for sounds above some size. For a 2 second Ogg file, it seems to be about 1.2 times as fast, and for a 90 second Ogg file it's about 35 times as fast.

I don't know what to suggest because I don't know what's going on here, but maybe it could do some of sort of "ignore the Decoder's buffer size and load the whole thing as fast as possible" thing?

Comments (8)

  1. hahawoo reporter

    Sure thing!

    So... when audio is decoded, a space is allocated based on the buffer size, and then the audio is decoded into that, and then it loops again until everything is decoded, and then it shrinks the memory space down to take out any excess allocated memory, and it's like this because it's not possible/quick to find out exactly how much space the decoded data will use, and the problem with just having a huge 100MB buffer size or whatever is that it uses 100MB.

    Is my understanding based on wild guesses correct? :D

    Would it be possible to guess the decoded size based on the file type and size?

    Or would it be possible to double (or multiply by some amount) the buffer size every loop, so that larger files can also decode in a reasonable time but there is never more than two (or whatever number) times as much memory allocated than is needed?

  2. Bart van Strien

    The same decoders are used for streaming sources, which means they can't spend too much time decoding either (the audio thread won't be able to supply enough data), which basically means there's very little we can change in a decoder itself to make it faster at bulk-decoding, we could, of course have newSoundData default to a larger buffer than newSource, though, for instance.

  3. Boolsheet

    The big performance difference you observed is mostly an issue with 0.8.0 and Windows' memory allocator and has been resolved for the next version. (issue #376)

    Of course there will be a function call overhead when creating SoundData with a Decoder that has a small buffer size, but that should be negligible.

    Changing the default Decoder buffer size when used for SoundData seems easy enough. There won't be a huge increase in performance though.

  4. hahawoo reporter

    Thanks for the info!

    I think this is a complete duplicate of #376 actually, sorry about that. :D I think I found it at some time, but didn't read it carefully enough, maybe that's where I subconsciously got the idea of an exponentially expanding buffer. :P

  5. Log in to comment