Hi Jason, On Tue, Jan 19, 2010 at 8:43 PM, Jason Daly <[email protected]> wrote: > If I were to implement an OpenAL AudioSink, I'd imagine you'd want it to be > a plugin (so the OSG can still be compiled without OpenAL). How would you > envision this plugin being tied in to the core? I started on an OpenAL > plugin last week, but I hit a wall when trying to figure out how to do this. > > The ReaderWriter interface works great for file-based plugins, but the > AudioSink seems like it's different enough that a new kind of interface is > needed. Do you agree? If so, would this interface also live in osgDB? > Would it be part of Registry, like ReaderWriter, DotOsgWrapper, etc.? > > Any other thoughts?
I have been thinking about the potential of an osgAudio library that abstracts away from the implementation details of OpenAL and keeps the door open to multiple implementations, and then within this have some form of registration of the audio implementation, then the audio implementations would plugin in to this, or like osgViewer just be built into the osgAudio library. osgViewer and it's handling of GraphicsWindow implementation might be a reasonable model for this. An straight audio sink is rather more straight forward than this though... so perhaps one could just have a slimline AudioSystemInterface/Factory class a bit like osg::GraphicsContext::WindowingSystemInterface singleton and then have this be where you register your scheme for implementing the AudioSink. Then in the plugins that need an audio sink it can go to this singleton and grab and implementation. The plugin might also use osgDB to load a plugin to force the registration of a implementation of a AudioSystemInterface. Such an approach would be easier to graft on than writing a full blown osgAudio library. Robert. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
