Assets.loadAudioBuffer parses audio track on the main thread

[EliteMasterEric]

Something I noticed while doing profiling.

When calling lime.util.Assets#loadAudioBuffer(id) on the main thread, the expectation is that all the loading and processing would be done by another thread (platform permitting).

Lime does retrieve the byte data for the asset asynchronously, as expected. However, once the asset is fully read, it then casts the Byte data to the target type, which HTTPRequestMacro converts into a call to fromBytes on the target type. This call is done on the main thread, and for most types the performance hit is miniscule.

For an AudioBuffer, however, this requires calling (on native) lime_audio_load_bytes, which decodes the data as a WAV file or an OGG file as needed. This takes time depending on the size of the audio file; for example, in Friday Night Funkin', decoding the main menu theme (a 1:52 OGG took 320.44ms to decode).

Since this is happening on the main thread, this results in a stutter during loading.

As a Future is already being used to load the byte data on a thread, processing of that byte data should also be done on a thread.