Having an Audio Atlas?

Question

Problem

I have 100 textures and I want to easily load them all without writing 100 lines of code loading them all.

Solution

Use a texture atlas. Use this to pack them. Use pixijs or something like that as it has native support for texture atlas

Problem

The same problem but with audio.

My Proposed Solution

Use a sound atlas. Merge all the audio into one, have a json recording the time stamps to beginning and end.

However, this solution has flaws. How will I update the sound to know whenever to stop the sound without going slightly under or over the time? Is this solution even reliable? Is there a tool that we can use for this? Are there better solutions than what I proposed?

Answer 1

Why would you write individual lines of code for loading each texture/sound?

That sounds like something you should load from a manifest file, so that adding/changing assets is just a data change, not a code change - no need to recompile. Your loading code then just loads the manifest, and loops through loading the assets identified inside.

You can take this a step further with data baking, where you combine the manifest and all its referenced files into one binary, load it as one big blob, then walk through the manifest portion to find the memory offsets within for each contained asset. This is mostly an optimization for loading speed, since it combines many small reads into one big read, and you can "pre-digest" the data into whatever binary representations your game uses internally, rather than decoding them on load.

Even with the data baking approach, each sound asset still retains its own identity as a separate data object, rather than being a set of timecodes in a single massive audio stream, so you should not have to modify the code that plays/interacts with individual sounds.

Answer 2

The main reason you use a texture atlas is not because you want to reduce the amount of lines of code to define or use multiple small textures. If you have a lot of textures, all that information will likely be in a data file, or automatically generated code anyways.

We use texture atlases because when you're drawing stuff on the screen, it is much faster to draw a lot of sprites with one draw call, where each sprite takes from a different area of a large atlas, than to draw each sprite with a different texture, and therefore a different draw call. The trade in simplicity vs performance is generally acceptable, so atlasing textures, especially for GUI elements is a very common operation nowadays (don't forget to turn mipmapping off).

With audio, this doesn't really apply. Audio mixing is performed in regular (not GPU) memory, so it doesn't really matter if multiple audio clips are separate, or in a single large audio "atlas". Furthermore, it can add a bit of complexity, since there is an additional seek operation for every clip that you want to play.

If you want to do an audio atlas, go ahead. It will most likely not affect performance, but if you find that it makes managing your audio files easier, then it might be a good idea for your use case.

As to how to go about making an audio atlas, I'm not aware of many tools that do this for you, but I think it should be relatively easy to hack a quick tool, for example in C#, with NAudio to read, write and manipulate audio files. You can add padding between the audio files if you think that is necessary, and output your data in Json, or whatever file format you want.