Hi Sukender, On Thu, Nov 27, 2008 at 10:07 PM, Sukender <[EMAIL PROTECTED]> wrote: > And maybe we should have a look to some other libs too, such as SFML ( > http://www.sfml-dev.org )?
This just adds more dependencies...include OpenAL so I'm not sure it's make things any simpler than just integrating with OpenAL ourselves. >> I would also try to keep things decoupled so items like a Manager >> would be something that is implementation dependent, rather that >> something that end user need worry about. > > Sorry I don't understand. Do you mean you're in favor of my second idea > (having a kind of priorirty for sounds that the plugin would use to > automatically turn on/off sounds to fit the limitation of the number of > sources)? In my paragraph above I was referring to the desire to keep implementation details including any managers that might be written I don't have any strong opinions on the topic, others have far more experience with using audio in scene graphs, I was hoping that they would dive in and comment... > Having a separate thread sounds fine to me. CPU is not used enough for audio! > Maybe a good occlusion computation would add immersion; so I think a separate > thread is better. Should there be audio update and cull/"render" traverals > for the viewer then? Having the Viewer manage an audio traversal/and or threads for it wouldn't be difficult. Conceptually you render the audio in a similar way to you manage graphics so the the cull/draw for graphics and cull/play for audio could sit comfortably side by side. > I'm also too busy to work on osgAudio, but I'd like to help as much as I can. We'll if neither have the time, and as no one else has dived into this topic to volunteer we will just have to be patient. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
