I’ve been evaluating FMod, and have been very impressed with it’s capabilities. I would like to license it for my next product, but I had a few basic feature requests that I thought run by you.
1] Functions to get and set a user value on samples, streams, and all major structures manipulated by the external API. These sorts of functions are really critical to being able to write a nice wrapper for fmod. (ie, setting the userdata to a pointer to the wrapper object) example:
signed char F_API FSOUND_Sample_SetUser( FSOUND_SAMPLE *sptr, unsigned long userdata );
unsigned long F_API FSOUND_Sample_GetUser( FSOUND_SAMPLE *sptr );
2] FSOUND_Sample_SetName – this would be a really nice function to have for debugging purposes. This way, when I load samples from my consolidated filesystem using FSOUND_LOADMEMORY, I can correctly set it’s internal filename. (Presently FSOUND_Sample_GetName returns “” in such instances)
3] Totally nitpicky, but presently when I’m shutting down FMOD while it’s playing one or more samples, it will usually result in at least one ‘pop’. Currently, I’m preventing it with the following sequence, but it would be nice if FMod would zero out the primary buffer before shutting down to avoid this. (Note this happens on a number of machines I’ve tested on, but as an example, it’s happening on my motherboard’s integrated audio which is a Creative ES1373)
// This sequence is to ensure that the shutdown will be clean (no cracks or pops)
Sleep(75); // Have to make sure the FMod thread gets a chance to run to apply these changes before FSOUND_Close() I think. Setting this sleep value lower will result in the ‘pop’ still being there.
// Finally, close the soundsystem
4] Overtly and Incredibly Nitpicky, but why not build the FMOD_ErrorString() into the DLL api, instead of having it as a static function in a header file?
Thanks for your time,
- Nick asked 15 years ago
By ‘really critical’ I imagine you mean in terms of callbacks? If so, then yes a userdata pointer can be handy in order to get a pointer to the object that represents that stream or music.
Not everyone wants several KB of error string text in the DLL. FMOD is designed to be as small as possible, therefore the error strings are separate so you can optionally include them in your application.
1. By ‘really critical’ I imagine you mean in terms of callbacks? If so, then yes a userdata pointer can be handy in order to get a pointer to the object that represents that stream or music.
Just as you say, in order to get a pointer to the class that represents the sound, stream or music. For callbacks, and also for retreiving meta-info stored in the wrapper concerning the sample.
4. Not everyone wants several KB of error string text in the DLL. FMOD is designed to be as small as possible, therefore the error strings are separate so you can optionally include them in your application
shrug like I said, it’s a totally minor request, but if compiled and UPX compressed into the FMOD .DLL (since it’s upxed anyways), we are talking literally less than 1k. In the static link version of FMOD, it would be dead code eliminated if never called.
If you’re wrapping fmod you should be storing that sort of info in your own structure and storing the fmod sample pointer in that structure as well.
Of course, but this would provide a way to get a pointer to that structure from an FMOD sample pointer. Other than just doing stuff with wrappers, I can think of a million other uses for this sort of thing, and nearly all robust 3rd party API’s have similar mechinisms.
Its not supposed to pop, and i’ve never heard it pop. If it pops, thats a new sound introduced, the behaviour is supposed to be that the mixer stops, so it just goes quiet. with a bit of testing thats what it seems to do here. I could only blame the driver in that case, i wouldnt like to have to sleep in the close function else i would get too many complaints of the close function being slow.
I suppose i can try clearing the buffer, you can do the same thing if you want to test the theory – FSOUND_DSP_ClearMixBuffer
Hrmm, that FSOUND_DSP_ClearMixBuffer didn’t seem to help either, perhaps it is a driver problem as you suggest… Is it possible that this is a systemic problem with a large range of different integrated audio chipsets? I’ve noticed this behavior on at least 5 machines all with different motherboards and integrated audio chipsets and drivers(including my current home machine which lists as a CMI8738 PCI Audio Device). In each case the previous code removes the pop. The ‘pop’ sounds like the buffer repeating part of the last thing that was in it when close is called. Hrmm…
Please login first to submit.