Question about differences between osgAudio Low Level and openalpp

[Peter C.]

Hello, I was wondering if anyone could provide any insight to this.
Right now I'm trying to work on converting an osgAL/openalpp program
to osgAudio. I was wondering if anyone could provide any feedback as
to the difference in how osgAudio handles low level stuff, compared to
how openalpp handles low level stuff. I am trying to determine the
differences between the two and if it's feasible to just completely
replace the openalpp with osgAudio using OpenAL. A few key
requirements however are the ability to check audio file sizes, and
the ability to load OGG format files. I tried porting the openalpp as
directly as possible over to osgAudio, however it segfaulted when
trying to load the sound system. I don't know exactly why it did it,
and I've been on that problem a for a good month now (in my spare
time, I'm primarily a college student, with a bit of open source work
on the side). I'm now evaluating the actual differences between using
osgAudio for everything, and mixing in openalpp. Are there any key
differences in functionality or implementation I should know about?

Thanks,
Peter

[Chris 'Xenon' Hanson]

Basically, osgAudio should replace everything that osgAL provided. The requirements
didn't call for wrapping everything in openALpp, so I didn't. It's possible that there are
important functionalities you use which are in openALpp and not in osgAL/osgAudio. In this
case, you could either get the openALpp handles from within osgAudio manually, and call
the openALpp APIs you need (and limit yourself to only using openALpp) or, discuss how
those functionalities might be added to osgAudio with both openALpp and FMOD backend
implementations.

> Thanks,
> Peter

--
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

[Peter C.]

Thanks, I'll have to do some more research on methods to do this stuff
that is required. I'll have to go over the audio code some more from
the old code and see what would need to be implemented to osgAudio
that was covered by openALpp.

> Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.comhttp://www.alphapixel.com/

[Paul Martz]

Hi Peter and Chris -- If your app used to interface with both osgAL and
openalpp, then I'd think the most straightforward way to port would be to leave
the openalpp-interfacing code alone (no changes should be required; as far as I
know, the openalpp API didn't change when osgAL became osgAudio), but port the
osgAL code to osgAudio.

In your osgAL code, the things you'd have to port would be:
* Use the new namespaces (global search and replace)
* Use .h on the header files, maybe change header path names
* Make sure you set up the Listener correctly (we changed this to provide
better support in multi display environments)

Maybe other stuff too, but that's all I can think of. The wiki has some porting
notes.

I agree with what Chris said: if you really do want to port your openalpp code
to use only the (backend-independent) osgAudio API, and you find any
functionality missing, then let's discuss how we might support it for both
OpenAL and FMOD backends.
-Paul

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