Advice before I go much further with this

I have a series of vocalized sounds per character (there are other examples, however vocalized sound is a decent one for the following)… seeing as it is impossible (for most people) to say more than one thing at any given time, I started playing around with dumping all related clips into a single audio file and creating audio tasks that start at specific offset and run until a specific duration of time has elapsed.

It works… seems like it works fairly well… but, before I go to far with this. Is anyone else using this approach and how is it working out for ya? Any regrets? Any benefits you found from doing this?

Depending on the type of game you are making… audio seems as if it could get disorganized fairly quickly.

Anyways… Thanks in advance for any input.

The smae principle id used in the egosoft games (the x ones at least http://www.egosoft.com/games/x_rebirth/info_en.php) All of them have 1-x large audio files with spechparts.

However I would go one extra step, store the vocals as single files, and make a audiobatcher tool, that batcehs all togehter and writes the offsets into a propertiesfile/hashmap. In game never specify the offset, but only the name and lookup the offsets.

This prevents the need to reorganise everything if a file gets replaced with a slightly longer one ect

1 Like

Note that this can’t work with streamed audio though, because using an offset is broken in the lib we’re using (ogg vorbis).
So i guess having a very big audio file as Empire suggested would be a problem.
We really suck at audio…

<cite>@nehon said:</cite> We really suck at audio....

That was funny :stuck_out_tongue:

I’ve had issues with streaming audio that is longer than say… 1 second? (ish) Oh wait… this was trying to loop the streamed audio… ignore this. Is streaming best for small or large files? I would think larger files you don’t want gobbling up memory. Which means… if I take the approach I was talking about, I’ll potentially run into significant limitations the further I go with it.

What would suggest as a potential alternative?

<cite>@Empire Phoenix said:</cite> The smae principle id used in the egosoft games (the x ones at least http://www.egosoft.com/games/x_rebirth/info_en.php) All of them have 1-x large audio files with spechparts.

However I would go one extra step, store the vocals as single files, and make a audiobatcher tool, that batcehs all togehter and writes the offsets into a propertiesfile/hashmap. In game never specify the offset, but only the name and lookup the offsets.

This prevents the need to reorganise everything if a file gets replaced with a slightly longer one ect

Mmmmm… I like the audio batch idea! Thanks =)

And… nice site! The game looks really cool. What platform are you using there?

Theoretically you could annotate your fiels in name? with further information, so and batch it by type, so if you only have x char on screen you can unload all voice for y.

1 Like
<cite>@Empire Phoenix said:</cite> Theoretically you could annotate your fiels in name? with further information, so and batch it by type, so if you only have x char on screen you can unload all voice for y.

I’ve had the hardest time just determining the best way of organizing the audio data into something that makes sense… it will more than likely be a combination of annotative naming and sub-directories… however my head starts to swim because there are tooooooo many choices. Do I base it on how I am handling the audio… or the in-game function of the audio… or classify it by entity… or… and the list goes on and on.

I guess while I continue to get advice from smarter people than me I can break the whole task system out to it’s own thread so I can get seamless looping of indexed audio working. And start using pause as apposed to stop for larger clips from looped indexed audio to minimize the appearance of repetitive loops.

Problem is… I fixate on things like this >.<

Any suggestions for handling instanced sounds?

And… super important questions concerning audio data:

Reading through the AL 1.1 spec, it looks as if the audio data’s source buffers should be stored once and reference by srcName, however… I know you still need individual audio nodes for positioning, etc, etc. Does anyone know if the audio data buffers are tracked and shared the way JME ensures textures are pushed once and referenced texture index? If not… will I hit any issues if I attempt to shared the AudioData between AudioNodes?

Well… the system dropped into place nicely. The game is an MMO with extensive AI for computer controlled “followers” you can use for grouping when other people are not available. You can either use hired NPCs or other characters you have created for your account. Seeeew… long story short, I loaded up the game summoned 3 followers and as they made there way to the player character they sat around grunting at each other.

Usually… this would make me say “Um… you all have f’ing issues”, but in this case… I was happy to see everyone acting like babbling idiots.

Looping indexed audio works good… no audible gap when looping the offset clip, so I am thinking it works correctly.

Still on the FIXME list:

  • Ensuring that audio data is shared if and where it can be.
  • Deciding on a method for handling single clips and instanced audio
  • Atm, each entity runs it’s own audio manager. I’m not seeing an issue with this, though my test zone only has about 50 NPCs, my player character, any summoned followers I load and a secondary client if I run it. On top of this, I will need a global audio manager for music, ambient noises, etc. And this is running the server and client(s) on my PoS PC.

The last point raises the question, how would other people approach this? A single global manager for ALL audio, or the way I current have this set up?

Single global manager for all audio.

…that way if you ever start to run out of channels you can intelligently prioritize without having to rip apart lots of code. Plus, it’s a sensible design anyway.

1 Like
<cite>@pspeed said:</cite> Single global manager for all audio.

…that way if you ever start to run out of channels you can intelligently prioritize without having to rip apart lots of code. Plus, it’s a sensible design anyway.

Thanks for pointing this out… this was actually not designed at all lol… it was a fifteen minute throw together last night, a frustration point with how to organize the files in some sensible manner and then I finally got around to dropping it into the client and trying it about 30 minutes ago (or so).

Because this is all relatively new to me… I was wondering how you would go about managing the tasks: Quick explination:

A task has a game specific audio key that groups sounds that would never be played at the same time… for instance multiple variations of sword hits (ok… bad example… but to save time… pretend it is a good example). Would you store the tasks local to entity and have the audio manager iterate over the list of entities > list of current tasks? Or store the tasks locally in the manager?

Stupid question… but I have had no sleep since the night before last due to a raging migraine and would love to work on this to keep my brain focused on something other than feeling like SH*T… but processing is going slower than usual (heh… feel free to tag me here… I set myself up for it).

Heh… just realized… I meant to say: has a game specific audio key + an entity requesting the execution of the task are important. /sigh

I have no advice. In my design, sounds are entities just like everything else. Well, they’re a component on an entity but more often than not a sound will have its own entity until it’s done.

<cite>@pspeed said:</cite> I have no advice. In my design, sounds _are_ entities just like everything else. Well, they're a component on an entity but more often than not a sound will have its own entity until it's done.

Is every sound it’s own indivi-jew-ile file/audionode?
Are you creating these as needed? Reusing defined audionodes for non-streamed audio?
Are you preloading the assets?

Maybe you would be the right person to ask… are audio buffers shared when a sound is used by multiple audionodes? Um… more specifically on OpenAL side of things, are buffers loaded once and referenced by srcName? Or is each audio using a single sound requesting a new srcName for the same data?

I’m having trouble tracking down this information, as it isn’t really clear in the spec, and it would definitely play a fairly significant role in how I end up going about things when I do finally design a system for managing the audio assets.

Every played sound would be its own audio node. I create them as needed. I wrap them in my own class.

I do not preload assets… they are cached as they are used.

My understanding is that everything but streamed audio is cached. The fact that there is an initial pause for big audio files to play the first time but not subsequent times would corroborate this.

1 Like
<cite>@pspeed said:</cite> Every played sound would be its own audio node. I create them as needed. I wrap them in my own class.

I do not preload assets… they are cached as they are used.

My understanding is that everything but streamed audio is cached. The fact that there is an initial pause for big audio files to play the first time but not subsequent times would corroborate this.

Thanks… I really was unclear as to whether or not I would have to manage this or not.

One last question. You cache as you go regardless of file size, yes?

@t0neg0d said: Thanks.... I really was unclear as to whether or not I would have to manage this or not.

One last question. You cache as you go regardless of file size, yes?

Yes… but I stream every thing that’s anywhere near large to avoid keeping stuff around in memory. I don’t really understand why one giant file is good so I don’t know what I would do in that case.

<cite>@pspeed said:</cite> Yes... but I stream every thing that's anywhere near large to avoid keeping stuff around in memory. I don't really understand why one giant file is good so I don't know what I would do in that case.

They are actually pretty small… after being batched. Really small, is more accurate. It’s just a hell of a lot easier to manage than 15 variations of a sound in individual files, saves a bit of space (this is moot however considering file size) and less asset loading. Plus you can use the same mechanism to vary things like footsteps, so you never get the same repetitive loop… ever! There are less AudioNodes to manage… less adding/removing these nodes from the scene graph, etc, etc… anyways… you get the list of potential benefits. Of course there are down sides as well… just like anything else.

Heh… actually, for others benefits… I’ll expand on the footstep scenario:

You have a single audio file containing, say… 12 variations of footfalls. All white space is removed, because the spped at which the individual clipps will be played back is totally dependant on how you define your audio task.

So… your player is moving at speed x:
Your audio task is set to random repeat at a fixed duration between clips based on the current speed.
Now, you player starts to run.
No separate audio file, just an alteration (or replacement) of the current audio task

This will work for infinite variations of movement speed and never produce a loop that is repetitive.

For running, I just increased the speed in my case. :slight_smile:

Edit: duh… which of course I did in audacity because we can’t set the speed. nevermind me.

You’ll want to allow interaction between sounds and other entities.
E.g. an NPC might have its battle cry interrupted by that squishy sound from under a rock. For a less drastic example, imagine an NPC starting to tell a joke, then noticing an approaching officer - he might cancel the joke, or continue in a whisper. Or imagine music systems that fade out the “lazy afternoon” tune and fade in the battle theme as soon as enemies are near.
The basic pattern I’m seeing is: Most decisions that a game makes can be modified at the next frame; the decision to play a sound is something that will stay in effect over many, many frames, so if the next frame decides something about what sounds should play, it needs to be able to modify the previous decisions. The data should be reachable for the code that makes these decisions, so if the sound is, say, emitted by a scenegraph object, the sound information shoud probably be tied to that scenegraph object.