Re: [osg-users] osgAudio / osgAL
Hi Robert, hi everyone, 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. Oh, I didn't know. You're right. 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... Well, I'd really like if anyone interested in the topic says something... 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. Great thing then. 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. At this moment I'm trying to use OpenAl-Soft instead of OpenAL for osgAL. I think I'll try to work (a little bit) on simplifying the integration/build of osgAL and later on osgAutio despite of my work. I'll maybe only write natural language ideas (= code nothing) in a first time. 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
Re: [osg-users] osgAudio / osgAL
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAudio / osgAL
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/
Re: [osg-users] osgAudio / osgAL
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
Re: [osg-users] osgAudio / osgAL
Hi Sukender, I was to develop osgAudio I would use osgAL/OpenAL as a template, much in the same way as you seem to be look at the topic. I'd also see how SDL audio might map as this has cross platform audio support that might be reasonable implementation for non spaitialized sound. 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. I would have thought that one might be able to capture the camera position relative to listener/sound sources by using the existing cull traversal as the way to extract the required info to pass on to OpenAL. Threading and multiple camera traversals might throw this a bit though... so perhaps a standard alone audio traversal would be appropriate as one would only have one audio context. Perhaps the ideal would be to allow the viewer to run an audio thread that runs in parallel with the cull/draw traversal threads. I am overloaded with my existing work so I can't take on any of this work myself, I'll happy cheer on from the side lines though. I certainly want to see an osgAudio merged into the core OSG. Perhaps a feature for OSG-2.10. Robert. On Thu, Nov 27, 2008 at 1:37 PM, Sukender [EMAIL PROTECTED] wrote: 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
Re: [osg-users] osgAudio / osgAL
Hi Robert, I am overloaded with my existing work so I can't take on any of this work myself, I'll happy cheer on from the side lines though. I've never met you personally, but I just can't picture you as a cheerleader with pom-pons and such... ;-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAudio / osgAL
Hi Robert, I was to develop osgAudio I would use osgAL/OpenAL as a template, much in the same way as you seem to be look at the topic. I'd also see how SDL audio might map as this has cross platform audio support that might be reasonable implementation for non spaitialized sound. And maybe we should have a look to some other libs too, such as SFML ( http://www.sfml-dev.org )? 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)? I would have thought that one might be able to capture the camera position relative to listener/sound sources by using the existing cull traversal as the way to extract the required info to pass on to OpenAL. Threading and multiple camera traversals might throw this a bit though... so perhaps a standard alone audio traversal would be appropriate as one would only have one audio context. Perhaps the ideal would be to allow the viewer to run an audio thread that runs in parallel with the cull/draw traversal threads. 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? I am overloaded with my existing work so I can't take on any of this work myself, I'll happy cheer on from the side lines though. I certainly want to see an osgAudio merged into the core OSG. Perhaps a feature for OSG-2.10. Robert. I'm also too busy to work on osgAudio, but I'd like to help as much as I can. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ On Thu, Nov 27, 2008 at 1:37 PM, Sukender [EMAIL PROTECTED] wrote: 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
[osg-users] osgAudio / osgAL
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
