Channels disappear from Events, sound stops

(Georgy Meshkov) #1

We’ve got a map with many (>100) looping events, with about 50 in playing state, 32 of which are real, others - virtual.
Some of the sounds suddenly stop playing without notice.

I have checked that event->stop() is not called. Well, I’ve checked all my “event->” occurances and found that none of these is called when the sound stops.
My guess was that the sound just gets virtual, so I’ve added a debug output every frame showing the number of channels in event’s channelGroup hiearchy. I’ve found out, that when the sound is playing, I have 1 non-virtual channel.
When the sound abruplty stops, the total channel count becomes 0. The traverse shows that an event has a channelGroup, which has one child channelGroup, which in turn has no channelGroups and no channels (when the sound was playing it had channelGroup->channelGroup->1 channel).

What can be the cause of this channel disappearing and how can I fix it?

Upd: Looks like my sound’s real cannel is “stolen” by some other sound which goes from virtual to real. Is it expected that my sound’s channel doesn’t just go to virtual state but completely disappears? Also this sound is quite loud so it shouldn’t be virtualized by other quieter sounds.
I’m still confused about what’s going on.

Upd2: Seems like a multithreading problem inside FMOD. I have updatet to the latest fmod Ex/Designer 4.44.47 and used logging libs and dlls (there were non in my version 4.40.06) - and the problem disappeared! On non-logging 4.44.47 the problem does still reproduce. So I guess that some synchronization is done when logging, which hides a mulithreading error. Or there are other differences in L dlls?

(Brett Paterson) #2

Hi Georgy.
Are you calling FMOD from different threads? The answer is to not do that. Only FMOD 5 / Studio is thread safe with the API, FMOD4 is not.

Logging version of FMOD only does a print to the tty or log file, there is not much else that it does of any relevance.

The logging version does do 1 more thing, it checks your float parameters to see if they are bad and returns FMOD_ERR_INVALID_FLOAT. Is it possible you’re passing bad floats? (if so your error checking could find that anyway).

(Georgy Meshkov) #3

Thank you for the answer, Brett. Unfortunately, I can’t check absolutely all requests in reasonable time, but I’ve checked that I’m passing only valid floats via FMOD::EventParameter::setValue. Also I’ve checked that FMOD::Event::start calls arrive from main thread and most likely no other functions are called from other threads.
Can you suggest something else?

(Georgy Meshkov) #4

Some more input: increasing the real software channels count helped, the sound doesn’t stop any more. But this takes more resources and makes virtual channel system unusable.
The problematic setup requires quite a lot of sound events, which are generated at high rate, so I can’t debug it thoroughly even having the FMOD source available. But probably the problem is in updateChannels, where some voice goes from virtual to real, kicking the real channel from under my poor sound.

(Brett Paterson) #5

I would simplify your logic and make sure you are updating the virtual voices with System::update every frame, and making sure you dont have leaking voices that you are not stopping. If you’re using events, make sure you have oneshot=yes in the event property sheet so that you dont just keep events active forever.

There is probably stealing going on and it is to do with your logic, make sure you stop everything that needs to be stopped, and monitor what is playing, and their audibility etc. There is no reason for everything to just go quiet.

(Georgy Meshkov) #6

Thank you again. I’m goin to answer soon via the support email - as soon as I get the response from our marketing team regarding sending you some screenshots.