0
0

Hello,

I think I have some trouble with FMOD. I inserted this code into a blank project and linked against FMOD Ex (latest version):

[code:mrytyfed]

include <cstdio>

include <cstdlib>

include <windows.h>

include "fmod_errors.h"

include "fmod_event.h"

include "fmod.hpp"

const int MaxVirtualChannels = 256;
const int MaxChannels = 16;
const int MaxUpdate = 64;
const int MaxInstancePerUpdate = 4;

define ERRCHECK(R) \

{ \
FMOD_RESULT result; \
result = R; \
if ( result != FMOD_OK ) { \
printf("FMOD error! (%d) %s\n", result, FMOD_ErrorString(result)); \
return EXIT_FAILURE; \
} \
}

int main( void ) {
FMOD::EventSystem * events;
FMOD::System * system;
int i, j;

ERRCHECK(FMOD::EventSystem_Create(&events));
ERRCHECK(events->getSystemObject(&system));
ERRCHECK(system->setSoftwareChannels(MaxChannels));
ERRCHECK(system->setHardwareChannels(0, MaxChannels, 0, MaxChannels));
ERRCHECK(events->init(MaxVirtualChannels, FMOD_INIT_NORMAL, NULL));

for ( i = 0; i < MaxUpdate; i++ ) {
FMOD::Sound * sound;
FMOD::Channel * channel;

ERRCHECK(system-&gt;createSound(&quot;ding.wav&quot;, FMOD_DEFAULT, NULL, &amp;sound));
for ( j = 0; j &lt; MaxInstancePerUpdate; j++ )
  ERRCHECK(system-&gt;playSound(FMOD_CHANNEL_FREE, sound, false, &amp;channel));
ERRCHECK(system-&gt;update());
printf(&quot;%d.\n&quot;, i);
Sleep(200);

}

for ( i = 0; i < MaxUpdate; i++ ) {
FMOD::Sound * sound;
FMOD::Channel * channel;

ERRCHECK(system-&gt;createSound(&quot;ding.wav&quot;, FMOD_DEFAULT, NULL, &amp;sound));
ERRCHECK(system-&gt;playSound(FMOD_CHANNEL_FREE, sound, false, &amp;channel));
ERRCHECK(system-&gt;update());
printf(&quot;%d.\n&quot;, i);
Sleep(1000);

}

ERRCHECK(events->release());

return EXIT_SUCCESS;
}
[/code:mrytyfed]

and I get a strange effect: after a while (around ab. 4 samples played) sound "goes into background". When all (overlapped) samples are stopped and they are started over with a higher delay (1 sec) everything turns back to normal.

Note: I used the standard Windows "Ding" sound sample to reproduce this. I think delay times those cause this kind of problem might differ on other computers.

That’s all. Do anybody have any idea? Am I use FMOD Ex in right way? (However, it should tolerate this…(?))

Thank you in advance.

  • You must to post comments
0
0

Please, somebody… :) Tell me something…

  • You must to post comments
0
0

Here is some system specific details:

[code:gz3wophs]

Sound Devices

        Description: Realtek HD Audio output

Default Sound Playback: Yes
Default Voice Playback: Yes
Hardware ID: HDAUDIO\FUNC_01&VEN_10EC&DEV_0882&SUBSYS_10430000&REV_1001
Manufacturer ID: 1
Product ID: 100
Type: WDM
Driver Name: RtkHDAud.sys
Driver Version: 5.10.0000.5127 (English)
Driver Attributes: Final Retail
WHQL Logo’d: Yes
Date and Size: 5/25/2005 17:55:58, 3134976 bytes
Other Files:
Driver Provider: Realtek Semiconductor Corp.
HW Accel Level: Full
Cap Flags: 0xF5F
Min/Max Sample Rate: 100, 192000
Static/Strm HW Mix Bufs: 33, 32
Static/Strm HW 3D Bufs: 33, 32
HW Memory: 0
Voice Management: No
EAX(tm) 2.0 Listen/Src: Yes, Yes
I3DL2(tm) Listen/Src: Yes, Yes
Sensaura(tm) ZoomFX(tm): No
Registry: OK
Sound Test Result: All tests were successful.
[/code:gz3wophs]

[code:gz3wophs]

System Information

..
Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.050301-1519)
..
BIOS: BIOS Date: 03/20/06 18:53:51 Ver: 08.00.10
Processor: Intel(R) Pentium(R) 4 CPU 3.00GHz (2 CPUs)
Memory: 1024MB RAM
Page File: 299MB used, 3698MB available
..
DirectX Version: DirectX 9.0c (4.09.0000.0904)
..
DxDiag Version: 5.03.2600.2180 32bit Unicode
[/code:gz3wophs]

And some notes: if I set the hardware acceleration level to a lower level, the whole effect turns around to a delayed "bang" of simulatenous sounds (may be it is because of the software emulation). It is the same in case of setting the output type to FMOD_OUTPUTTYPE_WINMM.

Can it be because of a driver bug? I do not think that the mixer thread could starve, because it is a very light weighted application :)

  • You must to post comments
0
0

i’m not sure what you’re trying to do, you create 64 sounds then play them 4 times each, meaning immediately you’re playing 256 sounds. You then play 64 sounds straight afterwards. This is a really strange test. As you only specified 16 software voices, there will be a lot of voices going virtual then swapping back in at the end.

If you’re trying to play 4 sounds at once, you’re not.. you’re playing hundreds.

  • You must to post comments
0
0

Dear Brett,

Sorry for the inconvenience, I admit that I forgot to describe the situation itself. This "strange test" is trying to model this, so without the whole program (what I cannot copy & paste here for many-many reasons) it could seem to be a bit bizarre.

Okay, let us see some explanation, then. As a matter of fact, the problem appears only in the first loop, the second loop is only a check — because when the system tries to play those hundreds of sounds it goes silent for a while, so I want to check whether it went off forever.

The heart of this problem is about the first loop. Yeah, I am trying to play ab. 256 sounds at once, almost simultaneously, with only tiny time deltas between each instance. I correct my previous (topic starter) post, where I wrote: "after a while (around ab. 4 samples played) sound "goes into background"". Because of this, it wanted to mean that "after a while (around ab. 4th time of 256 or even more sounds were played at once) sound "goes into background"".

However, I think you could catch it: a lot of voices go virtual, so the continous swapping kills(?) the sound quality. Based on this, I assume that I only need to minimize (optimalize) the number of those simultaneous sounds played at once (per update()).

Can I ask FMOD to prevent this kind of "overloading" somehow?

  • You must to post comments
0
0

Use priorities, or increase the number of real/software voices. You dont normally do this unless you understand voices are going to be cutting out because you are playing too many at once.
A 3d world where sounds go quiet then swap out is not noticable. Artifically spamming 2d voices is going to give you this type of artifact – yes.

  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.