openvrml-develop

[openvrml-develop] OpenAL sound support in OpenVRML

[-oli- <ol...@fr...>]

Hi, all!

As I wrote some weeks ago, I'm going to integrate OpenAL-support for the 
sound in OpenVRML.
Here I have some questions regarding this:

(1) In which method(s) can I implement the assignment of the spatial 
parameters (position, direction) of the sound to the OpenAL properties? 
NodeSound::render() or NodeAudioClip::update() or NodeAudiClip::render(), 
which doesn't exist yet. Regarding this, the method should be called 
whenever the position of the Sound-Node or the ViewPoint-Node changes. 
Besides that, also the time-dependend functionality in NodeSound::update() 
should be maintained.

(2) The WAV-File is read totally into memory at the moment (see audio.h) 
and then put chunk by chunk to the dsp-device (see NodeSound::update()). Is 
this right?


Btw: OpenAL (see http://www.openal.org/) is an OpenSource platform 
independend API for 3D-audio, developed by Loki Software, now maintained by 
Creative Labs.

As OpenAL uses a cones and VRML ellipsoids to define source directivity, 
I'm going to use OpenAL only for the location of the sound sources 
(spatialisation) and do the directivity stuff in OpenVRML "by hand".

Any tips/opinions/hints are welcome!

	-oli-
	(Oliver Baum)

Re: [openvrml-develop] OpenAL sound support in OpenVRML

[Braden M. <br...@en...>]

On Mon, 2002-04-08 at 10:41, -oli- wrote:
> As I wrote some weeks ago, I'm going to integrate OpenAL-support for the 
> sound in OpenVRML.

Okay. I'm gonna be a bit more explicit than I was before in order to
ensure expectations are set appropriately. I don't want you to complete
this project and then be surprised by its reception.

I don't think OpenAL is the best solution for audio in OpenVRML. At one
time it looked like it might be; however...

        * OpenAL's primary user and developer (Loki) is no more.
        * There was never a (successful?) attempt to package OpenAL in a
          way that would be palatable to end-users and OS distributions.
          Even now, the OpenAL Web site directs persons looking for
          "1.0" to CVS. The project has reached 1.0, and there's *still*
          not a tarball.

So OpenAL is difficult for end-users to install, and prospects for
continued support and development seem dim.

What this means:

        * *Yes*, I would accept a patch for OpenAL-based audio support.
        * This support would be disabled by default. If someone wanted
          to build with it, they'd need to configure with
          "--with-openal" or somesuch.
        * If OpenVRML also had support for some other audio solution (I
          mentioned GStreamer before, and I still think it's our best
          bet under Linux), I would not be inclined to spend too much of
          *my own* energy maintaining multiple audio solutions in
          parallel.

If you think I'm trying to steer you toward GStreamer instead of OpenAL,
you'd be right. However, I appreciate that you may have your own
motivation for wanting to use OpenAL, and I have no intention of
belaboring the issue beyond this posting. I appreciate that your work
*will* improve OpenVRML, even if it's not exactly what I'd do. :-)

> Here I have some questions regarding this:
> 
> (1) In which method(s) can I implement the assignment of the spatial 
> parameters (position, direction) of the sound to the OpenAL properties? 
> NodeSound::render() or NodeAudioClip::update() or NodeAudiClip::render(), 
> which doesn't exist yet.

That logic belongs in the Sound node.

> Regarding this, the method should be called 
> whenever the position of the Sound-Node or the ViewPoint-Node changes. 
> Besides that, also the time-dependend functionality in NodeSound::update() 
> should be maintained.

In the old architecture, that logic would belong in VrmlScene. In the
new architecture, it belongs in SoundClass.

> (2) The WAV-File is read totally into memory at the moment (see audio.h) 
> and then put chunk by chunk to the dsp-device (see NodeSound::update()). Is 
> this right?

As long as we aren't bothering with streaming, I think that's
acceptable. However, I'm not much of a "sound guy", so I might not know
what I'm talking about here.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] OpenAL sound support in OpenVRML

[Thomas F. <tf...@us...>]

Just a few comments about this

Braden McDaniel wrote:

>On Mon, 2002-04-08 at 10:41, -oli- wrote:
>
>>As I wrote some weeks ago, I'm going to integrate OpenAL-support for the 
>>sound in OpenVRML.
>>
>
>Okay. I'm gonna be a bit more explicit than I was before in order to
>ensure expectations are set appropriately. I don't want you to complete
>this project and then be surprised by its reception.
>
>I don't think OpenAL is the best solution for audio in OpenVRML. At one
>time it looked like it might be; however...
>
>        * OpenAL's primary user and developer (Loki) is no more.
>        * There was never a (successful?) attempt to package OpenAL in a
>          way that would be palatable to end-users and OS distributions.
>          Even now, the OpenAL Web site directs persons looking for
>          "1.0" to CVS. The project has reached 1.0, and there's *still*
>          not a tarball.
>
>So OpenAL is difficult for end-users to install, and prospects for
>continued support and development seem dim.
>

Loki hasn't really been involved with OpenAL for quite some time outside 
of hosting the site and CVS. Creative Labs has really been the main 
driver behind it. Creative has made distributions available on their 
developer site for Windows and Mac (see 
http://developer.creative.com/scripts/DC_D&H_Games-Downloads.asp?opt=2) 
and, from recent mail on the openal mailing list, has recently taken 
over hosting the CVS repository as well...

>
>What this means:
>
>        * *Yes*, I would accept a patch for OpenAL-based audio support.
>        * This support would be disabled by default. If someone wanted
>          to build with it, they'd need to configure with
>          "--with-openal" or somesuch.
>
This sounds reasonable.

Tom

Re: [openvrml-develop] OpenAL sound support in OpenVRML

[-oli- <ol...@fr...>]

Hi!

I will give some comments to my planned work on OpenVRML in this message:
- I need the OpenAL support in OpenVRML for my own puroposes, as I'm 
writing a diploma thesis about virtual acoustics.
- I will use, develop and compile it under Windows (98 and 2k) with M$ 
VisualC++ 6.0, and as I don't know much about makefiles, I will _not_ be 
able to produce a patch which enables compiling with "--with-openal". I'm 
inserting my own source with "#if use_openal" at the moment, so someone 
else can adapt the makefiles.
- I am using the OpenAL distribution from the Creative website (see Tom's 
mail).

At 20:43 08.04.2002 -0400, you wrote:
>        * *Yes*, I would accept a patch for OpenAL-based audio support.
>         * This support would be disabled by default. If someone wanted
>           to build with it, they'd need to configure with
>           "--with-openal" or somesuch.
>         * If OpenVRML also had support for some other audio solution (I
>           mentioned GStreamer before, and I still think it's our best
>           bet under Linux), I would not be inclined to spend too much of
>           *my own* energy maintaining multiple audio solutions in
>           parallel.

That's okay.

>If you think I'm trying to steer you toward GStreamer instead of OpenAL,
>you'd be right. However, I appreciate that you may have your own
>motivation for wanting to use OpenAL, and I have no intention of
>belaboring the issue beyond this posting. I appreciate that your work
>*will* improve OpenVRML, even if it's not exactly what I'd do. :-)

I looked on the GStreamer website. It seems to be a powerful solution for 
media processing, but there is no windows support (yet), so I cannot use it 
at this time.


Thanx for answering my questions!

Regards

         -oli-
         (Oliver Baum)

Re: [openvrml-develop] OpenAL sound support in OpenVRML

[Braden M. <br...@en...>]

On Mon, 2002-04-08 at 20:58, Thomas Flynn wrote:
> Just a few comments about this
> 
> Braden McDaniel wrote:
> 
> >On Mon, 2002-04-08 at 10:41, -oli- wrote:
> >
> >>As I wrote some weeks ago, I'm going to integrate OpenAL-support for the 
> >>sound in OpenVRML.
> >>
> >
> >Okay. I'm gonna be a bit more explicit than I was before in order to
> >ensure expectations are set appropriately. I don't want you to complete
> >this project and then be surprised by its reception.
> >
> >I don't think OpenAL is the best solution for audio in OpenVRML. At one
> >time it looked like it might be; however...
> >
> >        * OpenAL's primary user and developer (Loki) is no more.
> >        * There was never a (successful?) attempt to package OpenAL in a
> >          way that would be palatable to end-users and OS distributions.
> >          Even now, the OpenAL Web site directs persons looking for
> >          "1.0" to CVS. The project has reached 1.0, and there's *still*
> >          not a tarball.
> >
> >So OpenAL is difficult for end-users to install, and prospects for
> >continued support and development seem dim.
> >
> 
> Loki hasn't really been involved with OpenAL for quite some time outside 
> of hosting the site and CVS. Creative Labs has really been the main 
> driver behind it. Creative has made distributions available on their 
> developer site for Windows and Mac (see 
> http://developer.creative.com/scripts/DC_D&H_Games-Downloads.asp?opt=2) 
> and, from recent mail on the openal mailing list, has recently taken 
> over hosting the CVS repository as well...

I knew Creative had supported OpenAL, but I didn't realize they were
throwing significant development effort at it. That's good news.

The major problem I have with OpenAL being our primary audio solution is
the lack of a distribution tarball for which users can
"configure;make;make install". If development on OpenAL is continuing,
then there is hope for that to improve as well.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] OpenAL sound support in OpenVRML

[Braden M. <br...@en...>]

On Tue, 2002-04-09 at 03:14, -oli- wrote:
> - I will use, develop and compile it under Windows (98 and 2k) with M$ 
> VisualC++ 6.0, and as I don't know much about makefiles, I will _not_ be 
> able to produce a patch which enables compiling with "--with-openal". I'm 
> inserting my own source with "#if use_openal" at the moment, so someone 
> else can adapt the makefiles.

Good; that will facilitate the configure option. Tom or I can help with
that when the time comes.

> At 20:43 08.04.2002 -0400, you wrote:
> >        * *Yes*, I would accept a patch for OpenAL-based audio support.
> >         * This support would be disabled by default. If someone wanted
> >           to build with it, they'd need to configure with
> >           "--with-openal" or somesuch.
> >         * If OpenVRML also had support for some other audio solution (I
> >           mentioned GStreamer before, and I still think it's our best
> >           bet under Linux), I would not be inclined to spend too much of
> >           *my own* energy maintaining multiple audio solutions in
> >           parallel.
> 
> That's okay.
> 
> >If you think I'm trying to steer you toward GStreamer instead of OpenAL,
> >you'd be right. However, I appreciate that you may have your own
> >motivation for wanting to use OpenAL, and I have no intention of
> >belaboring the issue beyond this posting. I appreciate that your work
> >*will* improve OpenVRML, even if it's not exactly what I'd do. :-)
> 
> I looked on the GStreamer website. It seems to be a powerful solution for 
> media processing, but there is no windows support (yet), so I cannot use it 
> at this time.

My thinking is that we'd use GStreamer on Linux, DirectX (or maybe
Quicktime) on Windows, and Quicktime on Mac. That probably sounds like
overkill for audio; and it would be, if we didn't have the MovieTexture
issue to solve as well. I think we'll need these dependencies *anyway*
for good MovieTexture support, and so it will be convenient to use their
facilities for streaming audio as well.

However, since your thesis is focused on audio, I can see how expanding
your work to a generalized streaming media solution would be a
distraction.

Best of luck to you, and I'll try to help however I can.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>