[osgaudio-users] FMOD hardware detection

[Doug McCorkle]

Hello,

When using FMOD is there anyway to determine what hardware it is detecting when the engine is initialized? On linux we are trying to get 5.1 and 7.1 working with osgAudio using FMOD and are having trouble debugging what FMOD is detecting. Does anyone have any ideas how we could provide debug output through osgAudio that would help us debug initialization? Also, will FMOD automatically detect a 7.1 enabled system like it does with 5.1? Thanks.

Doug

--
You received this message because you are subscribed to the Google Groups "osgAudio-users" group.
To post to this group, send email to osgaudi...@googlegroups.com.
To unsubscribe from this group, send email to osgaudio-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/osgaudio-users?hl=en.

[Doug McCorkle]

On Apr 28, 2010, at 8:08 AM, Doug McCorkle wrote:

> Hello,
>
> When using FMOD is there anyway to determine what hardware it is detecting when the engine is initialized? On linux we are trying to get 5.1 and 7.1 working with osgAudio using FMOD and are having trouble debugging what FMOD is detecting. Does anyone have any ideas how we could provide debug output through osgAudio that would help us debug initialization? Also, will FMOD automatically detect a 7.1 enabled system like it does with 5.1? Thanks.

I just found this:

http://www.fmod.org/forum/viewtopic.php?t=11193&highlight=linux

[Chris 'Xenon' Hanson]

I just looked into this, and osgAudio doesn't really have an API exposed for this. I
could make one, and implement it for FMOD, but I'm not sure if openAL has an analog or
what it might be. So, I could do it if somebody really wanted it, but I think for most
common cases one can just call the FMOD system methods Doug mentioned. It seems to me that
it's not like you'd probably leave code like that in production programs, and as a result
it's a bit out of osgAudio's main scope, which is to play sounds.

But if anyone feels otherwise, I can tackle it.

--
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen

[Doug McCorkle]

On May 6, 2010, at 12:08 AM, Chris 'Xenon' Hanson wrote:

>
> I just looked into this, and osgAudio doesn't really have an API
> exposed for this. I
> could make one, and implement it for FMOD, but I'm not sure if
> openAL has an analog or
> what it might be. So, I could do it if somebody really wanted it,
> but I think for most
> common cases one can just call the FMOD system methods Doug
> mentioned. It seems to me that
> it's not like you'd probably leave code like that in production
> programs, and as a result
> it's a bit out of osgAudio's main scope, which is to play sounds.
>
> But if anyone feels otherwise, I can tackle it.
>

Currently in the OpenAL implementation openalpp/AudioBase.cpp (lines
35-133) there is information that is printed about what hardware is
being used by the OpenAL backend. It seems like the code that I posted
could be added to the FMOD backend (maybe in a special debug function)
that would enable users to print information about the hardware
drivers that are available and which one is being used. This could all
be controlled through the OSG debug output utilities. I think this
information would be valuable when trying to debug why some hardware
is not being detected or selected properly by FMOD by default.

Let me know what you think.

Doug

[Paul Martz]

Doug McCorkle wrote:
> Currently in the OpenAL implementation openalpp/AudioBase.cpp (lines
> 35-133) there is information that is printed about what hardware is
> being used by the OpenAL backend.

> ... This could all be

> controlled through the OSG debug output utilities.

Currently, openalpp doesn't have a dependency on OSG. Well, OK, to be honest,
the CMake system is set up to link openalpp against OSG, but none of the
openalpp source files include any OSG headers or use any OSG objects. If we
change the openalpp code to use the OSG notify system, then we are introducing a
dependency on OSG for arguably no good reason.

My personal preference is for libraries with some kind of global verbosity
control. But I'm not sure how this would work in osgAudio, where some parts of
the code use OSG's notify system, and other parts just write to std::cout or
std::cerr as they see fit.

I'm inclined to introduce a new default parameter to SoundManager::init, a bool
to control displaying init messages to the console. It would default to false,
which would mean the current openalpp behavior of writing init messages to
console would go away. But you could get this back by passing true. Once this is
done, I'd add some kind of equivalent support for FMOD as described in an
earlier post.

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

[Paul Martz]

Paul Martz wrote:
> I'm inclined to introduce a new default parameter to SoundManager::init,
> a bool to control displaying init messages to the console. It would
> default to false, which would mean the current openalpp behavior of
> writing init messages to console would go away. But you could get this
> back by passing true. Once this is done, I'd add some kind of equivalent
> support for FMOD as described in an earlier post.

Just checked this in as r44. This doesn't require an application change. The
default behavior is to not display initialization messages. Note that this is a
change for OpenAL, which previously always displayed init messages to console,
with no way to disable it.

I've changed the osgaudio example to enable init messages, by passing 'true' as
the 2nd param to SoundManager::init():

osgAudio::SoundManager::instance()->init( 16, true );

When I run the osgaudio example with the FMOD backend, here are the init
messages I get for my system:

Initializing FMOD. Detected 2 drivers.
0: Speakers / Headphones (SigmaTel High Definition Audio CODEC)
1: Digital Output Device (SPDIF Out) (SigmaTel High Definition Audio CODEC)

And if I run it with the OpenAL backend, I get this:

Initializing OpenAL.
No Generic Hardware in: Generic Software
Using OpenAL EAX2.0 extension