0
0

I experienced really slow load of sample bank data from memory in my project and modified the event parameter sample to include error logging and "timing" of loading sample data.

The modified version can be found here : [url:3pwiamzj]https://gist.github.com/anonymous/4d62c4c4147f30be470d[/url:3pwiamzj].

It takes >20 seconds to get a bank into loaded state in a debug build but "instant" in release build. The debug build is using the ‘L’ versions of FMOD so that version can not be used (if you are not trying to find a bug). I also experienced stalls of >2 seconds in Studio:update(…) with the ‘L’ version. Luckily I found out that the ‘L’ version was the culprit when doing this example :)

When hooking up a error callback (to the low level system) it reports errors like :

FMOD ERROR [34] – An invalid parameter was passed to this function.. [FMOD_ERRORCALLBACK_INSTANCETYPE_DSP 0x030B4D80] DSP::getDataParameterIndex(-2, 030B4C40:-1)

FMOD ERROR [33] – An invalid object handle was used.. [FMOD_ERRORCALLBACK_INSTANCETYPE_CHANNELCONTROL 0x003E0005] ChannelControl::isPlaying(0306F5F7:false)

FMOD ERROR [33] – An invalid object handle was used.. [FMOD_ERRORCALLBACK_INSTANCETYPE_CHANNELCONTROL 0x003E0005] ChannelControl::stop()

FMOD ERROR [33] – An invalid object handle was used.. [FMOD_ERRORCALLBACK_INSTANCETYPE_CHANNEL 0x003C0005] Channel::getPosition(0306F664:0, 2)

What does that mean (what have I forgot to do) ?

  • You must to post comments
0
0

The logging versions of FMOD can be much slower since they write all debug output to a file and in particular it does a line-by-line flush. The reason is that we don’t want to miss out on any debug output if a line of text is logged just before a crash. However it does have the unfortunate side effect of drastically slowing down execution. We’re revisiting this behaviour and have made a speed-up to the logging, which should come out next patch release.

As for the error callback, since Studio calls the low level API then it will trigger some of these more harmless errors as part of execution, such as DSP::getDataParameterInstance searching for parameters on DSPs, and low level channels going invalid as sounds finish. This is annoying but we don’t have a good workaround for now. It is possible that we could modify low level to selectively ignore Studio’s use of the low level API, although in any user of the low level API will get the same sort of callbacks that Studio is generating. For now you could modify your code to ignore these known types. That is not an elegant solution by any means, but it will work and would quick to implement.

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.