0
0

Hi,

I am trying to play events from a project file created by our sound designers. The problem I have is that each time I start one of these events, the Event::start call is taking upwards of 80ms!

This is happening on the PC only, on the XBox360 it is barely taking any time. I am using the non-logging libs (the logging ones exhibit the same behaviour but take even longer! No errors are being logged out either.)

I’m not playing any other events, there is just the one active at any time. The events are non-looping.

I can’t see anything obviously wrong with the events/sound banks. The samples are not set to stream from disk, which would have been my first guess. They are set to decompress into memory (PCM). They are also quite short samples (less than a second).

If I make my own project with just a couple of events to test this, then I don’t get this problem (although the start event call does still take over 1ms which still seems a little high).

Has anyone else come across something similar? What possible explanations could there be? What is Event::start doing that could take this amount of time?

Thanks in advance,

Dave

  • You must to post comments
0
0

Decompress into memory means, unless you’ve preloaded the data, it will actually load, and decompress the data when you call getEvent.

You should be using loadEventData to preload data.

  • You must to post comments
0
0

Hi Brett, thanks for the reply.

However, I don’t think that’s the problem.

Firstly, I am already using loadEventData to preload the data. Secondly, it’s not getEvent that’s taking the time (that’s almost instant), but Event::start.

To help me test this, I modified the simple_event sample code to load my project file, and start the event whenever the spacebar is pressed. I timed how long each call to Event::start takes by wrapping it with a pair of QueryPerformanceCounter calls.

Pressing space about once every second produces timing results like this:

30.890913 ms
0.906935 ms
43.897213 ms
0.861899 ms
0.951421 ms
53.594048 ms
0.946143 ms
56.468151 ms
0.876403 ms
72.098213 ms
82.845924 ms
82.013420 ms
0.967595 ms
1.000571 ms
0.929120 ms
0.912607 ms
73.113678 ms
0.823645 ms
0.800935 ms
68.263664 ms

So as you can see, while sometimes it take ~1ms (which still seems a little high for just one event), other times it can be ~70-80ms!

As I said in my previous post, on the Xbox360 the time taken is negligible. It’s only the PC that exhibits this problem.

So with all that in mind, and your intimate knowledge of what processes actually go on during a Event::start call, any further ideas as to what might be taking this time?

Thanks,

Dave

  • You must to post comments
0
0

Are you using the logging version of fmod and accidently timing the takes for the logging to happen? (on pc it is writing to a file).

  • You must to post comments
0
0

Hi Brett, sorry for the late reply – I’ve had a few days off work.

That’s a good guess, but not right I’m afraid. :(

I’m using the non-logging versions (fmodex_vc.lib & fmod_event.lib).

I have just tried this on two other machines in the office, and on those I get results like this:

0.515987 ms
0.007822 ms
0.493079 ms
0.008102 ms
0.482743 ms
0.011733 ms
1.411632 ms
0.012571 ms
1.409397 ms
0.009498 ms
0.010895 ms
0.557613 ms
0.008660 ms
0.573816 ms

As you can see, the times are much smaller (perhaps indicating that it is hardware/driver related?), but there is still a lot of fluctuation there – and the times are still hitting 1.5ms for a single call.

Any further thoughts?

Dave

  • You must to post comments
0
0

it is probably related to directsound hardware driver overhead. If you choose ‘force software’ in the wave bank screen that will eliminate that issue.

  • You must to post comments
0
0

A-ha! That does indeed make all the difference. Thanks.

I’m now seeing more sensible timings, like < 0.1ms.

I wonder, is there a way to force this in code, or at least query for the setting? I’d like to avoid wave banks creeping in later in the project with this property set incorrectly.

I know in the FMOD Ex API you can call System::createSound with the FMOD_SOFTWARE flag set, but I can’t see anything equivalent in the Event API.

Our sound designers are not in-house, and we do not have access to the source wav files etc., so checking/making any changes to properties for example is not as trivial as it might seem.

Cheers,

Dave

  • You must to post comments
0
0

What I do is when converting the FDP’s, is parse them through, replacing lines line <_PC_forcesoftware>0</_PC_forcesoftware> with <_PC_forcesoftware>1</_PC_forcesoftware>, and then writing the output out to a temp file. Then shell out to fmoddesignerCL.exe.

It’s fairly straight forward, and corrects any little problems that may creep in.

  • You must to post comments
0
0

[quote="dlomas":3kgsui8k]
I wonder, is there a way to force this in code, or at least query for the setting? I’d like to avoid wave banks creeping in later in the project with this property set incorrectly.

I know in the FMOD Ex API you can call System::createSound with the FMOD_SOFTWARE flag set, but I can’t see anything equivalent in the Event API.
[/quote:3kgsui8k]

We have just been bitten again by the "Force software" setting.

I assume there is still no way to check for this at run-time? I can’t see anything in the API documentation that would suggest otherwise.

One of our programmers has spent two whole days trying to track down several various bizarre/obscure bugs and crashes. All of which it now seems can be attributed to the "Force software" setting in the designer tool being left as the default – i.e. "No".

Please, please, please give us some way of checking for this at run-time. Either some setting on initialisation that will cause an error if we try and load/play any non-software banks, or a way of querying the Project/Group/Event for the setting so that we can assert ourselves. The FMOD_EVENT_WAVEBANKINFO structure already contains the load-type property (stream from disk, decompress into memory etc.), would it be possible in future versions to include the software/hardware mode as well for example?

I really don’t want myself or anyone else in my company to have to waste anymore time chasing down bugs caused by problems with the hardware processing. And judging by the number of threads here that end with Brett saying "Try setting the wavebank to ‘Force Software’…", we would certainly not be the only ones who might benefit from this.

a1psx’s workaround is not really appropriate for us because we do not currently do any processing/conversion on the FDP files. Strictly speaking, we only receive the FEV+FSB files from our contracted sound designers. (Sure we do get given the FDP files as well, but they are only for reference and not part of our build process).

Many thanks,

Dave

  • You must to post comments
0
0

if you use System::setMaxHardwareChannels(0,0,0,0) you should be able to avoid hardware all together.

We’re going to make force software the default in future versions of designer for win32 anyway. hardware support on pc is not worth supporting these days.

  • You must to post comments
Showing 9 results
Your Answer

Please first to submit.