I know you’re aware of the CPU usage problem with streams on OS X, but I’m seeing another problem which may or may not be related…
Streams created with FMOD_OPENMEMORY may crash after a couple seconds. File streams work, and non-streaming sounds created with FMOD_OPENMEMORY work as well. Seems the crash occurs in a thread spawn by FMOD:
Thread 4 Crashed:
0 <<00000000>> 0xffff89dc __memcpy + 572 (cpu_capabilities.h:189)
1 libfmodex.dylib 0x004923f8 FMOD::DSP::getUserData(void**) + 53964
2 libfmodex.dylib 0x00491448 FMOD::DSP::getUserData(void**) + 49948
3 libfmodex.dylib 0x00490ccc FMOD::DSP::getUserData(void**) + 48032
4 libfmodex.dylib 0x004a927c FMOD::System::getUserData(void**) + 26704
5 libSystem.B.dylib 0x9002c3d4 _pthread_body + 96
I first noticed this crash with an OGG file, but it also occurs with MP3 and AIFF (maybe others). Oddly, WAV and MOD don’t crash, but their seems to be some noise occurring while decoding MOD files. If they’re streamed it’s constant ticks/beeps/hisses but if they aren’t streamed there’s a long sequence of noise (while it’s decoding to memory) and then they’ll play fine. MOD, S3M, and XM had the same results.
This is with FMOD Ex 4.00.33 and Mac OS X 10.4.2
- Frank C. asked 13 years ago
[quote="brett":2hbrwipw]We can’t reproduce this at all.
We did just change fmod from pthreads back to carbon threads, due to the cpu usage issue, so when we do the next release try it out again and see if it behaves any differently.[/quote:2hbrwipw]
[quote="brett":2hbrwipw]I’m assuming the length you passed to fmod was correct, as i just learned we couldn’t reproduce this in the 33 version either.[/quote:2hbrwipw]
As far as I can tell the length is correct (the same files/sizes work when opened with FMOD_CREATESAMPLE | FMOD_OPENMEMORY). The memory streams also work with WAV files just fine, and with MOD files (though noisy) but OGG/MP3 crash consistently within a few seconds.
I’m running on a Dual 800 Mhz G4 if that makes a difference – I’ve seen problems with pthreads on Dual vs Single CPU Macs before, though disabling a CPU doesn’t prevent the crash in this case.
I’ll give the next release a shot and let you know how it works out.
Sorry – The thread crash was indeed my fault 😀 It was me overwriting memory that was causing the problem. The fact that some files worked was just a fluke (small files simply didn’t get trashed as fast as larger ones).
MOD files still produce noise while decoding though so you might wanna look into that (I’m pretty sure that one isn’t my fault!)
Thanks for the quick support as usual.
I hear clicks/pops while the MOD is decoding – i.e. for streams it’s intermitted clicks while playing, and when loaded as a sample there’s a couple seconds worth of clicking and it then plays fine.
This is definitely a Dual CPU quirk. If I disable a CPU there’s no noise. I can even turn the noise on and off by disabling/enabling the second CPU while playing back a streamed MOD.
Please login first to submit.