Extension to support access to the FMOD System class

[Doug McCorkle]

Hello,

We would like to call:
result = system->setOutput(FMOD_OUTPUTTYPE_ALSA);
result = system->setSpeakerMode(FMOD_SPEAKERMODE_5POINT1);

on the system that osgAudio is managing for FMOD. Unfortunately these methods must be called before init or after close is called. I would like to extend the AudioEnvironmentFMOD class. I was thinking we could do something with either a callback class or function pointers. Maybe a vector or some other container that we could pass into the AudioEnvironmentFMOD class to initialize the FMOD system class. What do others think?

Doug

[Chris 'Xenon' Hanson]

These are capabilities that aren't currently exposed by the existing APIs?

Is this something where we could hide it behind a generic interface that all subsystems
could support? Like, could you bury it behind a setPreference() kind of API:

setPreference("OUTPUT", "ALSA");
setPreference("SPEAKERMODE", "5POINT1");

So that any willing subsystem could recognize and implement these options, rather than
diverging into something FMOD-specific?

The FMOD implementation of setPreference would just stringmatch against the
preferenceName arg and then interpret the preferenceVal arg to match against enums, and
then do whatever is really necessary at whatever time is necessary.

> Doug

--
Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting.
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen

[Paul Martz]

On 3/11/2011 7:57 PM, Doug McCorkle wrote:

I'll let Chris comment on this, as I'm not familiar with the FMOD API. If it
really doesn't let you change these values after FMOD initialization, then it
seems reasonable that there should be a way to specify these parameters before
initialization.

--
-Paul Martz Skew Matrix Software
http://www.skew-matrix.com/

[Doug McCorkle]

On Mar 12, 2011, at 10:34 AM, Chris 'Xenon' Hanson wrote:

> On 3/11/2011 7:57 PM, Doug McCorkle wrote:
>> result = system->setOutput(FMOD_OUTPUTTYPE_ALSA);
>> result = system->setSpeakerMode(FMOD_SPEAKERMODE_5POINT1);
>> on the system that osgAudio is managing for FMOD. Unfortunately these methods must be called before init or after close is called. I would like to extend the AudioEnvironmentFMOD class. I was thinking we could do something with either a callback class or function pointers. Maybe a vector or some other container that we could pass into the AudioEnvironmentFMOD class to initialize the FMOD system class. What do others think?
>
> These are capabilities that aren't currently exposed by the existing APIs?
>
> Is this something where we could hide it behind a generic interface that all subsystems
> could support? Like, could you bury it behind a setPreference() kind of API:
>
> setPreference("OUTPUT", "ALSA");
> setPreference("SPEAKERMODE", "5POINT1");
>
> So that any willing subsystem could recognize and implement these options, rather than
> diverging into something FMOD-specific?

In my opinion this is an FMOD specific request. The requirement here is that we need to allow users to configure System before the init call. This is specific to FMOD.

I do not think we want to hard type an API as you laid out above. That always ends up being a maintenance nightmare in my opinion. Whatever solution we end up with I would like to put the majority of the development burden on the osgAudio developer rather than the osgAudio library. This has worked quite well for us in osgBullet.

Doug

[Doug McCorkle]

Anymore thoughts on this? If not I will work something up an commit it. This one is important to some current deadlines.

Doug

[Chris 'Xenon' Hanson]

On 3/14/2011 6:35 PM, Doug McCorkle wrote:
>> In my opinion this is an FMOD specific request. The requirement here is that we need to allow users to configure System before the init call. This is specific to FMOD.
>> I do not think we want to hard type an API as you laid out above. That always ends up being a maintenance nightmare in my opinion. Whatever solution we end up with I would like to put the majority of the development burden on the osgAudio developer rather than the osgAudio library. This has worked quite well for us in osgBullet.
> Anymore thoughts on this? If not I will work something up an commit it. This one is important to some current deadlines.

I think you understand the issue better than I, so I defer to your judgment.