0
0

Since fmod links to the current release version of libogg, I can’t use theora, which requires a from-cvs version of libogg. When I link in -logg and -lfmod, the fmod ogg functions manage to always win out and the theora attempts to play music fail.

Would it be possible to get a version of the .so that dynamically links to libogg and libvorbis rather than statically linking to them? This would fix the problem.

Jon (Slothy)
Programmer, S2 Games

  • You must to post comments
0
0

The .so is not staticly linked with Fmod.
I don’t think supporting Ogg Theora is a good idea as it is under active development, it would be better to stay for the first stable version. If you really want to add support for Ogg Theora, you ll have to use Fmod fille callback (FSOUND_File_SetCallbacks), create a custom stream (FSOUND_Stream_Create) and fill the buffer in a stream dsp (FSOUND_Stream_CreateDSP).

  • You must to post comments
0
0

I’m pretty certain that fmod does indeed contain libogg and libvorbis in it. The README.TXT file contains the license for Ogg Vorbis, and given that fmod supports Ogg Vorbis and doesn’t link to libogg or libvorbis, it is almost definitely statically linked.

I understand that Theora is under active development, I’m an old-timer with vorbis and such. It’s actually quite functional though – it is already being used by my game and works beautifully.

The problem isn’t even the audio playback (I don’t have it go through fmod at this point, it’s just writing to /dev/dsp). It’s that when I compile my app with -logg, the ogg_* function calls that my app makes are not handled by libogg, but are instead handled inside libfmod because libfmod also contains those function definitions. Unfortunately, the libogg that fmod is compiled against is unable to support theora, and so the application fails. If I compile my app without -fmod, it works perfectly.

An alternative to dynamic linking would be to rename the ogg_* and vorbis_* functions that fmod uses, so this kind of thing won’t happen, or to not export those functions in the library.

Jon

  • You must to post comments
0
0

Just to illustrate my point better, if you add -lfmod to the Theora examples/player_example.c gcc compile line, you’ll see that the audio doesn’t play correctly, you get mostly silence with a few chirps.

Jon

  • You must to post comments
0
0

yes, fmod is linked with the libogg/libvorbis library, the best way to get your app working is asking brett to do a “special” recompile with Ogg Theora lib. I don’t see easiest solution (another one is to hardcode symbols inside libfmod wich is illegal 😉 ).

  • You must to post comments
0
0

Well he could even do a special recompile with libogg from cvs instead of the libogg 1.0. Or dynamically link it. I don’t really want Theora even included in fmod since it’s still changing, I can -ltheora myself and not have to ask Brett for a new version every Theora release.

Jon

  • You must to post comments
0
0

I think your best solution would be to dynamically link to the FMOD library. Then you should be able to statically link the Theora library without a hitch.

Sly

  • You must to post comments
0
0

I was really not looking forward to that, then I realized you already supplied that awesome cross-platform fmoddyn.h. Wow, that took me all of 5 minutes to move it over to dynamic linking.

That rocks.

Jon

  • You must to post comments
0
0

[quote="brett":3re8lvoo]…especially when we have heavily modified it to make it more efficient, lower memory footprint etc.[/quote:3re8lvoo]

Would you consider submitting those enhancements to the Ogg and Vorbis codebase? That would benefit many people. Or are they fairly FMOD-specific changes?

Sly

  • You must to post comments
0
0

[quote="brett":2cb1ppx7]…but the main change was reducing the variable sizes down from doubles to floats, int64’s to ints etc…[/quote:2cb1ppx7]
Wouldn’t this affect final quality? I must admit I haven’t ever heard a difference between playing ogg in fmod or in winamp, but it sounds to me that the output would not be the same, or doesn’t it matter that much, since the final output is only 16bit anyway?

  • You must to post comments
0
0

I’d take the reduced memory footprint and faster code over a theoretical and very minimal (possibly not even detectable by human ears) degradation in sound quality.

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.