0
0

Still crashes at the same spot. This time with 26 active streams. It is crashing on the same indirect call (ecx+24h). Note that ECX isn’t valid.

Registers:
[code:1gt3phfu]
EAX = 054146D0 EBX = 00000040
ECX = FEEEFEEE EDX = 0012F1E0
ESI = 017E077C EDI = 00000400
EIP = 1004817D ESP = 0012F1D0
EBP = 0012F1E4 EFL = 00200202
[/code:1gt3phfu]

Context:
[code:1gt3phfu]
fmodex! 1004817D
fmodex! 10014CEF
fmodex! 10003929
fmodex! 1001F1A1
fmodex! 1000A2AC
fmodex! 1000FA1D
[/code:1gt3phfu]

Disassembly:
[code:1gt3phfu]
1004817D call dword ptr [ecx+24h]
10048180 test eax,eax
10048182 je 10048189
10048184 push 29h
10048186 pop eax
10048187 jmp 100481C4
10048189 mov cl,byte ptr [ebp-4]
1004818C mov eax,dword ptr [ebp+8]
[/code:1gt3phfu]

Is posting the above useful?

  • You must to post comments
0
0

I’ve been testing some more to make sure it isn’t my mistake somewhere, and here’s some more info:

The exact error is ‘Run-Time Check Failure #2 – Stack around the variable ‘tmpBuffer’ was corrupted.’

It seems that mp3’s work fine, but ogg’s don’t. I haven’t tested wma, but maybe it has something to do with the other errors reported in this thread?

  • You must to post comments
0
0

When should we expect you to post the fixed version? I’m kind of stuck at the moment without OGG and the clicks/pops are a bit annoying :) .

  • You must to post comments
0
0

I am simply playing a stream. I have a 4.1 sound system, and my speaker settings are correct.

If I initialize the stream with FMOD_HARDWARE, the sound plays on all 4 speakers correctly.

If I initialize the stream with FMOD_SOFTWARE, the sound only plays on the front speakers.

Should both modes not play the same by default? Or do I have to do something special for the SOFTWARE mode to play the same as the HARDWARE mode, on all speakers?

Cliff :)

  • You must to post comments
0
0

Sounds like a new version might be coming out soon, so it might go away with that one.

I’m getting an intermittent crash… it’s hard to nail down exactly what is causing it, since it doesn’t always happen and seems to happen randomly. I think it’s stream-related, since if I make all my sounds memory-based sounds it goes away, but that doesn’t necessarily mean that’s the cause.

Anyway, it crashes somewhere inside FMod on a call to System::update(). My stack trace looks like this:

[code:2d651gmz]FMODEX! 10048c81()
FMODEX! 10013ad9()
FMODEX! 1001e39b()
FMODEX! 10009de8()[/code:2d651gmz]

The assembly line that crashed is:

[code:2d651gmz]10048C65 push 10h
10048C67 lea eax,[ebp-14h]
10048C6A push 100568DCh
10048C6F push eax
10048C70 call 10053AD6
10048C75 mov eax,dword ptr [edi+2D0h]
10048C7B add esp,0Ch
10048C7E lea edx,[ebp+8]
10048C81 mov ecx,dword ptr [eax]
[/code:2d651gmz]

and eax is zero, so that’s why it crashed.

I dunno if any of that helps.

  • You must to post comments
0
0

ok, since this was beta, I was just making sure :)

Also, recently you have changed from using ints to floats, for such things as volume and balance.

Does that mean perhaps that Sound::getOpenState’s second parameter “unsigned int * percentbuffered” should also be changed to a float, and use values from 0.0 to 1.0 ?

(Just bringing this up, in case you missed it)

  • You must to post comments
0
0

I get a random crash in the VB5 IDE when developing using FModEx. I haven’t tracked down any particular cause yet, so that’s why I haven’t mentioned it yet. The error message is a fairly standard “that memory location could not be ‘read'”.

The strange thing is that it doesn’t happen when my application is actually running, there is just a random crash in the IDE at some point in the future. That’s not totally surprising, as VB programs run as part of the IDE while you’re developing them, but it’s not something that happened with FMod 3.

Is it possible that FModEx would have some kind of thread or process that might hang around after FMOD_System_Close() has been called, in a way that FMod 3 doesn’t?

Perhaps it will be fixed by one of the changes Brett has made already.

  • You must to post comments
0
0

At the moment, I include the id3lib in my project (and have for a while, because originally FMOD didn’t support tags), however it has now matured to a point where I can now remove id3lib.

There is however one call that I still use in id3lib that I can’t seem to find support for in FMOD.

I found the getFrequency function, but I can’t find anything to get the Bitrate.

This is the code I am using from id3lib to get the bitrate:

[code:3rrk5tdg]
const Mp3_Headerinfo *info = tag.GetMp3HeaderInfo();

// Get bitrate
if (info->vbr_bitrate > 0)
m_player->SetBitrate(info->vbr_bitrate);
else
m_player->SetBitrate(info->bitrate);
[/code:3rrk5tdg]

I’ve tried searching the help as well as fmod.h but can’t find anything to do with bitrate.

(I remember something about FSOUND_Stream_Net_GetStatus in FMOD 3, but couldn’t find an equivalent in FMOD 4)

Cliff :)

  • You must to post comments
0
0

I’m also seeing crashes sometimes on FMOD_System_Close(). I stop and release all streams that are playing before this, though. Do I need to call an Update before the Close maybe?

  • You must to post comments
0
0

I found an odd bug. Nothing serious, just some incorrect information from System::getNumDrivers.

If you call System::getNumDrivers after a call to System::getDriverCaps, you get more drivers than expected.

I have an Audigy Platinum eX which gives 2 drivers available with DirectSound: Primary Sound Driver and SB Audigy Audio [DC00]. However if I call System::getDriverCaps before init, I will always get 4 drivers available and they list as follows: Primary Sound Driver, SB Audigy Audio [DC00], Primary Sound Driver, and SB Audigy Audio [DC00].

GetDriverCaps returns FMOD_OK and all the correct capabilities are set. I call the following functions in the following order during initialization (in case it helps you spot some logic hole):

FMOD::System_Create
System::getVersion
System::setOutput
System::getOutput
System::setDriver
System::getDriver
System::getDriverCaps
System::setStreamBufferSize
System::init
System::set3DSettings
System::getNumDrivers
System::close
System::release

If any of those don’t return FMOD_OK I break out/return however this is all getting executed fine, just the number of drivers seems to be wrong. Remove the System::getDriverCaps step and it works fine.

It only does this with DirectSound. Asio, WinMM, NoSound, and WavWriter work fine.

  • You must to post comments
0
0

Hi

How long until PS2/PSP/Xbox/Xenon versions of FmodEx are available and will the license costs be greater to use FmodEx?

Thanks


ben crossman » core technology group » climax group
sheridan house, 114 western road, hove, east sussex, bn3 1dd. uk.
tel: +44 (0)1273 740800 fax: +44 (0)1273 740819

  • You must to post comments
0
0

Is WMA support broken in this build? It was working fine in beta 18.

  • You must to post comments
0
0

Cool

thanks for the info. I believe FmodEx to be the best solution to data driven sound (rather than Microsoft’s XACT or Sony’s Scream) and will pitch the idea to Climax.

Thanks


ben crossman » core technology group » climax group
sheridan house, 114 western road, hove, east sussex, bn3 1dd. uk.
tel: +44 (0)1273 740800 fax: +44 (0)1273 740819

  • You must to post comments
0
0

I get my program to crash with beta 19, while 18 was working fine.

I initialize fmod with
[code:1vf2ebpt]fmod_result = FMOD::System_Create(&fmod_system);
fmod_result = fmod_system->init(4, 0, (FMOD_INITFLAGS)(FMOD_INIT_NONREALTIME), NULL);
[/code:1vf2ebpt]
I open ogg files with
[code:1vf2ebpt]
fmod_result = fmod_system->createSound(fileName, (FMOD_MODE)(FMOD_SOFTWARE | FMOD_2D | FMOD_CREATESTREAM | FMOD_OPENONLY | FMOD_ACCURATETIME),NULL , &fmod_sound);
[/code:1vf2ebpt]
And i get data with
[code:1vf2ebpt]
fm_result = fmod_sound->readData(tmpBuffer, 2048, read);
[/code:1vf2ebpt]

When debugging, I get an error at the end of the function that called the readData, saying that the memory location near tmpBuffer is corrupted.
After my program accesses another variable, it crashes.
tmpBuffer is locally declared in that function, and I am certain that it is large enough.
(Declared as short tmpBuffer[2048], so it should be twice as large as necessary)

When I revert to beta 18 .dll, it works again.

  • You must to post comments
0
0

[quote="brett":2eokq09l]
PSP and Xenon are coming. We are now just waiting for hardware for Xenon to ship to us, and for PSP, well we are in the final stages of our (lengthly – 3 months now) application and Sony just have to give us the final “yes” or “no”. They said in the next 3-4 weeks.[/quote:2eokq09l]
I am a developer at an Atari game studio, and we are researching the available audio engines for Sony PSP.

What do you think the time-table would be for a FMOD PSP engine?

Thanks,
Dustin

  • You must to post comments
0
0

Hmm.. crash seems to be gone so far… I thought it was fixed last time, too… I’ll let you know after more testing.

I do have 2 new issues, though. OGG files don’t seem to work reliably anymore. Sometimes they play right, sometimes they seem to play the first buffer and stop. Also, after they play they start returning 0 for the position instead of the end of the file which caused me problems (I use that to determine when to kill the sound if the application is watching the position for lipsyncing).

Also, newly started streams are popping and clicking at start. This didn’t used to happen with 18 or older. I start streams paused, then set the 3d position if needed, volume, callbacks, etc. then unpause it. It is doing this on both hardware 3d and hardware 2d streams.

  • You must to post comments
0
0

[quote="Adion":3bwq5kdl]I get my program to crash with beta 19, while 18 was working fine.

I initialize fmod with
[code:3bwq5kdl]fmod_result = FMOD::System_Create(&fmod_system);
fmod_result = fmod_system->init(4, 0, (FMOD_INITFLAGS)(FMOD_INIT_NONREALTIME), NULL);
[/code:3bwq5kdl]
I open ogg files with
[code:3bwq5kdl]
fmod_result = fmod_system->createSound(fileName, (FMOD_MODE)(FMOD_SOFTWARE | FMOD_2D | FMOD_CREATESTREAM | FMOD_OPENONLY | FMOD_ACCURATETIME),NULL , &fmod_sound);
[/code:3bwq5kdl]
And i get data with
[code:3bwq5kdl]
fm_result = fmod_sound->readData(tmpBuffer, 2048, read);
[/code:3bwq5kdl]

When debugging, I get an error at the end of the function that called the readData, saying that the memory location near tmpBuffer is corrupted.
After my program accesses another variable, it crashes.
tmpBuffer is locally declared in that function, and I am certain that it is large enough.
(Declared as short tmpBuffer[2048], so it should be twice as large as necessary)

When I revert to beta 18 .dll, it works again.[/quote:3bwq5kdl]I thought readData outputs floats?

  • You must to post comments
0
0

As far as I know the format depends on the format of the file you open.
So for most mp3,wav,ogg,… it’s 16 bit stereo.

For s3m,xm,it,mod I think it’s indeed float.

  • You must to post comments
Showing 17 results
Your Answer

Please first to submit.