Hi Robert, hi everyone, I totally agree that we need an abstraction layer and plugins. So let's say "osgAudio" is that abstraction layer, and that "osgAL" is a future plugin based on the current osgAL work. - What would be in the osgAudio then? - Should we (and how could we do to) leave a degree of freedom to plugins so that users can access specific features (= not handled in osgAudio)?
I guess osgAudio has to be very simple. Here are some of my ideas: - As LightSources, there should be AudioSources nodes that we can position somewhere. - AudioSource may be absolute (= heard everywhere = no distance attenuation = no culling). - AudioSource should be attached to a Sound (= AudioData = buffer or stream + some parameters like doppler factor, gain, velocity...) - Sound should be able to read many formats/codecs (PCM, Vorbis...) - There should be a cache for sounds (for buffers but not for streams I guess!) - The user may update the Sounds parameters on update traversal (mainly for the velocity - For me, the physics will drive this value) - There should be Listeners, and the main Listener should be by default linked with the main camera (Is that easy to do?) - Sounds may be occuled, but I wonder if it's better to add occulder "geometries" in the world, or set a specific flag on existing geometries to say they occult sounds. Well this looks much like osgAL, but that's normal! However, I'd like to remove the presence of the osgAL manager if possible. About allocation/deallocation of internal sound buffers, I have two ideas: 1. As for lights, the user is limited to a given number and he has to manually switch on/off those (s)he wants. 2. This not be the matter of the user. Eventually (s)he could set their number, but not much more. The sources are given a base priority, which can be lowered if the sound is attenuated (= if listener is far). The 'n' most important AudioSources would then be active and the other inactive. Eventually, a parameter would have to say if AudioSources may or may not be stopped suring playing to leave another one play (= a more imporant one). Which one do you prefer? The second idea looks a little bit like the LightSourcesManager I wrote (that switch on the 8 most important lights), and that can easily be generalized. The advantage is simplicity for the user, and the drawback is that we then cannot remove the "osgAL manager" I told before. I hope this will help to see an osgAudio soon! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 27 Nov 2008 11:17:01 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit: > Hi Sukender, > > Previously I have looked at merging osgAL into svn/trunk, but on > review of the code decided that a straight merge was inappropriate. > For end user build simplicity OpenAL++ and osgAL would be best merged. > > The structure of an audio library for the core OSG are something I > feel need abstraction from any specific audio implementation. So in > my ideal world an osgAudio library would provide the basic glue for > adding audio into the scene graph, and the base classes that provide > the hooks into the implementations, then implementations would be > provided via plugins. No such library currently exists so it'd have > to be written. The need for abstraction is required to ensure that > future portability to embedded platforms isn't hampered by large extra > dependencies. > > Robert. > > On Wed, Nov 26, 2008 at 10:40 PM, Sukender <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I'd like to know who's interested in audio for OSG: >> - Who would like to use it? >> - Who would like to see some osgAudio included in OSG? >> - Who would like to develop such a thing? >> >> Well, actually I use osgAL, that depends on OpenAL and OpenAL++ (and Ogg and >> Vorbis if needed). It can do interesting things, including spatialized audio. >> I'd really like to see osgAL included in OSG but its author is not that >> active (he told me!) and I guess there is some work to be done before this. >> And to begin, the CMake build system for it (Compiling it was not that easy). >> >> But I also have to say that compiling OpenAL under Win32 was a PAIN (much >> more than osgAL), because I could not find TWO IDENTICAL libs that were >> structured the same way. I finally compiled from >> svn://connect.creativelabs.com/OpenAL/trunk, and I had to tweak the project >> files to fit my needs: >> - Added 'd' as debug suffix. >> - Added Win32 libs (because I'm using an Express version of VC). >> - Manually deployed the binaries by copying them at the right spot. >> Moreover, OpenAL needs DirectSound under Windows (!!!), so I also needed the >> DirectX SDK... >> >> If someone is ready to cleanup/structure/merge into OSG... PLEASE DO IT! :) >> >> Also feel free to tell anything interesting about audio in OSG. Maybe are >> there interesting cross-platforms and open-source libs? Thread's started! >> >> Sukender >> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
