LCL

Good ideas from the team that came out of this discussion include:

Naming Convention:
Agreed. There are no spaces in the path and everything is in fixed format lowercase and easy to interpret programmatically.

Pitchshifting:
Sounds like a good way to increase the # of unique sounds. I will have to mark sounds that will be pitch shifted and specify a range with which they can be shifted within.
The engine will handle this natively, I'm told.

Panning/Placement:
From what I've gathered so far with regards to stereo sound (and potentially 3Dsound) is that by tying the sound to an position/ entity on the map the engine sorts out panning and positioning depending on your speaker/soundcard configuration. If I'm right then, it would handle the sound placement in a stereo, surround, or "virtual surround” environment.

Sound Overload:
*Limiting # of Sounds on Playback*
Comment:
With respect to the sound overload comment, again I think this could be balanced based on different situations with some sort of priority system to limit the # of sounds at a time. (i.e. play up to X instances of resources and X instances of natural ambience at a time...not sure how this will work...but this is where I would like to get to. variables to balance the distribution of sound situationaly)

Comment:
The game sound code should be responsible for making sure we don't emit too many sounds of one type (a fixed budget for several classes as you suggest sounds good), while the low-level code makes sure that everything fits into the number of sound channels we have (which varies with sound card capabilities). This is because snd.cpp knows about the sound hardware, but not anything about the game itself.
OpenAL promises us at least 16-1 'sources'. High-end sound cards and software mixers typically have 64. A good ballpark figure seems to be 24, but we must be able to get along with 16.

Low-Level Audio Code already envisages 'application priority' to make sure voiceovers aren't dropped in favor of seagulls. If the game sound code were to automatically detect sound clusters, that would help a lot with reducing the number of active sources. In that case, it might be enough to assign a base priority by sound type (battle > chopping) and let the distance sorting (and fading - you don't hear stuff that's too far away) do the rest.

Comment:
1. Think about the idea of "automatically detecting sound clusters" more...keep a dialog going about whether this scheme continues to make sense.
2. Think about what the range of "base priority" would/should/could be, and I will work to apply it to the clips in the spreadsheet at some point. (If it's a go)

The idea was brought up that once the # of entites on screen goes over X, we could play different audio clips for the sounds of larger scale action.

Open questions on the table:

1.Who decides if 4 lumberjacks are to be combined, and how?
-Must decide on inclusion cut-offs and scope of workload. Start small and work our way upwards in intensity as necessary.

2.When updating all entities, I guess they would issue play requests every few seconds. After all are issued, we could look over the list, detect that >= 4 came in one area, and combine those.
-Do the entities issue sounds for the next 2 seconds all at once (all with a random start delay, so that we fill the 2 seconds)? In that case, the above might work.
-What about if the villagers stop chopping?
-The sounds would still be queued, how is this normally done?

3.Are there 'must hear' events that occur on the other end of the map and wouldn't normally be heard (because it's too far away)? How do we handle that?
OpenAL provides for 'minimum' gain (= volume), I guess that would effectively disable attenuation by distance.
- 1st thought is that yes there may be 'global' events (alarms) that you would want to use to notify the player of something that happened on the other side of the world. We will need to roll that around the rest of the team for input.

I continue to build more and more potential parameters onto each sample, that will hopefully make it easier to implement when the time come to start dropping the sounds in.

It is due to the highly responsive and knowledgeable team involved on this project that I've been able to navigate the heady waters of this project thus far, and just want to acknowledge all of their valuable comments.

Moving right along!
Until Next Time
LCL