0
0

Hi,
We developed a QT/C++ application that runs 7×24. Most of the audio is mp2 (few of them mp3) their duration is between 30 and 120 minutes.
Sometimes we get a tone signal that seems about memory. After this signal, we have to reboot system.

Our FMOD version is libfmodex64-4.44.15.so.

Tested on Debian 6, Debian 7.2, Debian 7.2 with rt kernel, ubuntu studio 13.10 and we had same problem on all of them.
Also we tested with both pulse and alsa.

Soundcards are Lola and EchoLayla3g. Interestingly, Lola was very predictable :), stops working always after 4 or 5 days. On the other hand, Echo Layla3G soundcards had random errors. Sometimes they worked for 10 days, sometimes tone appeared after a few hours.

At last, we used Valgrind to detect memory leaks. Before our test results, I want to give information about the application.

It uses 4 audio channels. In the initialization process 4 different objects are from the classes below:
[code:5i43xe64]
//parent class
FModPlayer::FModPlayer() : ICorePlayer() {
m_system = NULL;
m_sound[0] = NULL;
m_sound[1] = NULL;
m_channel[0] = NULL; //They are for mixing audio
m_channel[1] = NULL;
m_channelplaying = 0;
m_channelmix = 1;
unsigned int version;

m_result = FMOD::System_Create(&m_system);
ERRCHECK(m_result);

m_result = m_system->getVersion(&version);
ERRCHECK(m_result);


if (version < FMOD_VERSION) {
    printf("Error!  You are using an old version of FMOD %08x.  This program requires %08x\n", version, FMOD_VERSION);
}


m_result = m_system->setStreamBufferSize(65536, FMOD_TIMEUNIT_RAWBYTES);
ERRCHECK(m_result);

m_result = m_system->init(200, FMOD_INIT_NORMAL, 0);
ERRCHECK(m_result);

m_result = m_system->createChannelGroup("ChannelGroup", &m_channelGroup);
ERRCHECK(m_result);

}
[/code:5i43xe64]

[code:5i43xe64]
//class for first channel
FModMainPlayer::FModMainPlayer() : FModPlayer() {
m_result = m_system->setDriver(0);
}
[/code:5i43xe64]
[code:5i43xe64]
//class for second channel
FModPlaylistPlayer::FModPlaylistPlayer() : FModPlayer() {
m_result = m_system->setDriver(1);
}
[/code:5i43xe64]

[code:5i43xe64]
//class for third channel
FModStackPlayer::FModStackPlayer() : FModPlayer() {
m_result = m_system->setDriver(2);
}[/code:5i43xe64]

[code:5i43xe64]
//class for fourth channel
FPreviewPlayer::FPreviewPlayer() : FModPlayer() {
m_result = m_system->setDriver(3);
}
[/code:5i43xe64]

Later, we play music from one of channels. Most of the time we use at most two channels and we always release sound after playing.

Yet, Valgrind results were very interesting. Since it is in debug mode, while it is playing, we get FMOD alsa starvation errors. This wasn’t suprising because of debug mode. But we also get starvation errors while it was not playing anything. More interestingly, after we created FMOD object as above code and before playing anything we get starvation errors. Does FMOD open alsa channels after FMOD::System_Create?

We thought this may be a problem and we changed our strategy: Instead of creating four FMOD objects during initialization and using them for playing, we tried to create an FMOD object before each playback and as soon as it is stopped, we destroyed the object. And opened it for new playback.

This solution worked, at least our Lola has been working 11 days which is a record :)

I wonder how the above code creates alsa starvation messages before it is playing anything? Is it a memory leak?
Or we are doing something wrong?

  • You must to post comments
0
0

Once you call System::init FMOD will open the interface with the audio hardware and start playing.
The FMOD stream will continue until you call System::close, if you haven’t played any sounds FMOD will be passing silence to the sound card.

It is possible if FMOD is being heavily starved of resources that it can give warnings even when playing nothing as it sill feeds silence to the sound card (this is not a memory leak).

To verify FMOD memory allocation you can call FMOD::Memory_GetStats at any time to see what allocations have occurred, could you try this to verify there is no leak?
Also you can use the logging version of FMOD along with FMOD::Debug_SetLevel to display memory allocations and line numbers so you can get some indication of any leak.

  • You must to post comments
0
0

Thanks for replying.
I have one more question:
Why does FMOD pass silence? Is there any timeout for soundcard?

  • You must to post comments
0
0

It’s the way the buffered stream model works, we maintain several blocks of audio that get regularly submitted to the sound card, this ensures the hardware is never starved of audio. When starvation occurs you will hear the same fragment of audio playing over and over. Each time a block of audio is consumed we produce another one (which may be silent depending on what is happening inside FMOD). If we didn’t feed silence we’d need to pause (or on some platforms, tear down) the audio hardware when silence is detected which can be quite slow. Considering blocks of audio are generally 5 to 20 milliseconds we wouldn’t want to be starting and stopping the stream all the time.

If you do wish to halt the stream for FMOD Ex you would need to call System::close. For FMOD Studio some platforms support the new System::mixerSuspend feature to achieve the same result without losing the state of all FMOD objects.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.