0
0

[Apologies in advance if this had been addressed elsewhere and apologies for being verbose… I thought this may be a topic of general interest]

I’m looking at an application that would have a lengthy run time (perhaps all day) with various users entering and leaving and various networked participants entering and leaving.

I’m trying to get a handle on sound management and how the features of FMOD fit in. For all intents, the loading of static sounds and “sharing” them across channels all makes sense – we could hold a loaded sound for awhile to see if any (new) participant uses it and if not, release those resources.

Where I’d like a little better understanding is Event handling. Ideally, I’d have an event file set (FEV+FSB) associated with each unique equipment type that is participating. When a new participant enters via the network, the local machine would load the event file for that specific equipment. However, if it’s already loaded (ie, that type of equipment is already active due to another participant), then we can just play sound events from the already-loaded files.

When a participant leaves, we may never need the sounds for that simulated equipment again and I’d like to free the resources (again, we’d like long uptimes with free coming & going of participants, so I need to keep an eye on memory usage).

Here’s where I get fuzzy… from what I read, it appears that it isn’t efficient to create multiple EventSystem objects (although it’s supported). However, if I understand right, we can load multiple FEV+FSB files into a single EventSystem object.

First, am I correct in assuming that loading multiple FEV+FSB objects simply adds those resources into the pool? Meaning that if I load one file, I can walk through that file’s groups, and if I continue and load a 2nd file, then I now just have more groups and events at my disposal? (I guess I’m asking: Is loading event file A then loading event file B functionally the same as loading a single event file that contains the A and B groups+events?)

Now what I’m looking for is the best way to cleanly release those resources. I’m not sure that I understand the specific difference between EventSystem::unload() and EventSystem::release(). Does unload() empty the buffers but leave the EventSystem object intact? But release() empties the data AND destroys the object? Or is it more involved?

When a particular FEV+FSB set is no longer needed, I’d like to free THOSE resources, but it appears that with a single EventSystem object, I can only release ALL resources (i.e., [u:1flag2b7]ALL[/u:1flag2b7] FEV+FSB’s that I’ve loaded into that object). Is this indeed the case?

If so, does my application warrant the creation of individual EventSystem objects (one per FEV+FSB pair) where I could indeed release those resources individually to reclaim memory?

Or is it better to just keep track of the loaded files under a SINGLE EventSystem object and simply retain them throughout the scope of the application (because I cannot release them individually and I don’t want to flush ALL of them)?

I don’t yet have a handle on the overall size of the event files – they might not be bad, but I just don’t yet know.

I know this is somewhat vague, but without knowing just how much efficiency is lost with multiple EventSystem objects, I’m wondering if using multiple objects is a “generally, don’t” or a “DON’T EVER” kind of thing?

Thanks in advance,
Bill

  • You must to post comments
0
0

Short answer is, use one EventSystem – loading subsequent FEVs effectively merges their event hierarchy with the currently loaded hierarchy as you assumed – you can use EventGroup::freeEventData to selectively free wave data per group but currently you can’t selectively free the event data i.e. EventSystem::unload unloads everything. We will be implementing a way of selectively unloading event data sometime soon. Event data (which is what’s in the FEV file) is not very big but, in your case, it may add up over the course of a whole day. I suggest using freeEventData for now.

Cheers,

  • You must to post comments
0
0

[quote:2eul7g6p]multiple event system objects create a whole mixer there and sound card instance per object, so ‘dont ever’ is my answer.[/quote:2eul7g6p]

Understood. If I may sidetrack for a moment, I am curious as to why there would be “so much” additional overhead. In a simplistic hand-wave, my thinking is that mixing 4 sounds (z = a+b+c+d) is nearly the same as mixing a pair of two (z = a+b, y=c+d) and sending the results to HW channels. I assume I’m missing a ton of “real world” detail here?

[quote:2eul7g6p]loading subsequent FEVs effectively merges their event hierarchy with the currently loaded hierarchy[/quote:2eul7g6p]

This is good to know, and is a really nice feature. Loading multiple event files and ending up with an effectively combined hierarchy makes the group traversal task much more straight-forward.

[quote:2eul7g6p]you can use EventGroup::freeEventData to selectively free wave data per group[/quote:2eul7g6p]

Will freeEventData() unload not only the group info (group text, event list, parameter list) but also the referenced sound data (e.g., WAVs) as well? This seems to be what you’re saying, but I want to make sure that I’m understanding it right.

This seems to be a somewhat complex task because a sound resource may be shared among events in different groups? (i.e., car_group/horn may use beep.wav and truck_group/horn may also use beep.wav). So if I lose truck_group, is the API smart enough to “hold onto” beep.wav because other group(s) reference it?

[quote:2eul7g6p]Event data (which is what’s in the FEV file) is not very big[/quote:2eul7g6p]

Understood. It’s the related FSB data that concerns me. If I load an event file for one vehicle type and it leaves the simulation, I’d like to free up that sound memory because I may never see that vehicle type again.

Should I understand that (at least for now) that:
1) Use a single EventSystem object
2) FSB data, once loaded, is pretty much here to stay unless I want to unload [b:2eul7g6p]ALL[/b:2eul7g6p] FSB data

Thanks,

Bill

  • You must to post comments
0
0

>>> … merges their event hierarchy with the currently loaded hierarchy … <<<
so it means that indices are not the same after the merge I guess ?

  • You must to post comments
0
0

[quote:cvwxzrx1]Should I understand that (at least for now) that:
1) Use a single EventSystem object
2) FSB data, once loaded, is pretty much here to stay unless I want to unload ALL FSB data
[/quote:cvwxzrx1]
1. Yes.
2. No. freeEventData() does unload FSB data (which is the actual wave data in your wave banks). freeEventData() does not unload FEV data (which is the data describing an event – it doesn’t take up much room)

[quote:cvwxzrx1]so it means that indices are not the same after the merge I guess ?[/quote:cvwxzrx1]

Possibly. You can manage this by organising your hierarchy so things don’t overlap. Alternatively you can remap indices at runtime – when a bunch of events are loaded into an existing group they are added onto the end of the events in that group i.e. index of new event in group = index of new event + number of events in group before loading.

Cheers,

  • You must to post comments
0
0

Thanks for the fast reposnse

>>> … Possibly. You can manage this by organising your hierarchy so things don’t overlap … <<<
… that was my first guess, well at least will "force" us to use some convention … which is good

  • You must to post comments
0
0

[quote:3mzhbzic]We will be implementing a way of selectively unloading event data sometime soon[/quote:3mzhbzic]
Hi,
Are we likely to see this (FEV unloading) any time soon? I don’t see it on the feature schedule.
Thanks.

  • You must to post comments
0
0

Within weeks, not months. Can’t say exactly when.

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.