For the Google Summer of Code (GSoC) 2006, we had a student (Søren Bøg, aka avacore) work on a OpenAL 3D sound renderer for Crystal Space.
This was mostly working but there are a few remaining things to be done before we can integrate this code into Crystal Space.

Task status: MODERATE, no OpenGL required.

Branch history

See log:/CS/branches/soc/openal
The branch was merged in trunk in r28235 (2007/11/24, CS 1.3).

What is missing ?

Compared to the classical software sound renderer, the OpenAL renderer doesn't support sound event logging.
The sound event logger normally gets enabled using the following commandline parameters:
appname -plugin="crystalspace.sndsys.utility.eventrecorder" [-soundeventlog=/this/sound.log]

What changed ?

Quoting avacore:
iSndSysSourceSoftware3D was split into iSndSysSource3D for the 3D stuff, and iSndSysSourceSoftware for the software specific stuff.

Interface changes

* Added:

  • iSndSysListenerDoppler
  • iSndSysRendererOpenAL
  • iSndSysSource3D
    • has Get/Set Min/MaxDistance(float)
    • has Get/Set Position(csVector3)
  • iSndSysSource3DDirectionalSimple
  • iSndSysSource3DDirectional
    • has additional Get/Set methods for Inner & Outer cone: ie. GetDirectionalRadiationXXXXXCone()
    • has Get/Set DirectionalRadiationOuterGain(float)
  • iSndSysSource3DDoppler

* Removed:

  • iSndSysSourceSoftware3D

Compatibility matters

To keep compatibility, iSndSysSourceSoftware3D interface was restored and deprecated in r27978.
Note that CEL's pcsound uses software-renderer-specific interfaces, so it cannot use OpenAL for now. Fixed in cel:changeset:3100

Testing

The URL for the SVN branch is
https://crystal.svn.sourceforge.net/svnroot/crystal/CS/branches/soc/openal
Note that this branch should not be used anymore, now that it has been merged in trunk.

How to test ?

* Run asndtest.

Better use -fullbright for that one. You get in a room with several sound sources, one being mobile.

* Run sndtest. It should still run fine, using software renderer.

* You can set any CS app to use OpenAL renderer by setting the following configuration key-value pair:

System.PlugIns.iSndSysRenderer = crystalspace.sndsys.renderer.openal
Try it with sndtest for example, by setting the kvp in ~/.crystalspace/CrystalApp.sndtest.cfg (on *nix-like systems).

* ALSoundTest: a little test case application for OpenAL plugin: ALSoundTest.tar.bz2 (last updated: 2008-11-02 15h50 CET)

Discussions

#openal 2008-11-01 IRC log

Note: the two problems mentioned here are fixed by r31536 in trunk/1.9 & r31537 in 1.4 branch. 

KittyCat>  vknecht, btw, I did find a couple possible bugs in crystal space's openal plugin
vknecht>   KittyCat: oh ? sounds good :-)
vknecht is a bit late...
KittyCat>  vknecht, yeah. I haven't found the source of the problem with the noise when using 32768, though.
KittyCat>  one problem is that SndSysSourceOpenAL3D::PerformUpdate calls SndSysSourceOpenAL2D::PerformUpdate first.
           When the latter checks if m_Update is true, it sets the gain and then sets it to false. the former, then,
           would never see m_Update as true and never update the source properties
KittyCat>  a way to fix this would be to make SndSysSourceOpenAL3D::PerformUpdate not set m_Update to false,
           and call SndSysSourceOpenAL2D::PerformUpdate after the 3D properties are set
vknecht notes that cautiously
vknecht>   I'll forward that comment to avacore, and will look at it myself, but since I'm not so good at programming... :-)

KittyCat>  another is that when SndSysSourceOpenAL2D::FillBuffer calls m_Stream->GetDataPointers and potentially gets two data pointers.
           if they need to be combined, the temp array is given type ALuint
KittyCat>  this makes tempbuffer+length1 produce the wrong offset
KittyCat>  using ALubyte should fix that
vknecht>   mmm, I guess offset problem might be the cause for tapping and echoing
KittyCat>  yeah, I thought so too.. but I fixed that and I still get the noise
KittyCat>  honestly, I'm thinking the problem is somewhere in m_Stream->AdvancePosition
           or m_Stream->GetDataPointers (the actual functions, not the specific calls)
vknecht>   it's really great you looked that deep into it, thanks
KittyCat>  no problem
vknecht>   hopefuly avacore will find those comments useful, but you'd be most welcomed as a CS contributor, for sure :-)
vknecht>   on my side I've begun a little test app to check with different samples,
           and it seems it's generally stereo ones which have problems
vknecht>   but I don't have different enough samples yet to be sure
vknecht>   I think I'll also make that "magic" constant value a run-time configurable one,
           so that one can more easily mess with it ;-)
vknecht>   but yeah, most probably the real cause is elsewhere
KittyCat>  32768 bytes across 4 buffers should be plenty to keep the stream from starving.
           and having done some traces, it doesn't seem to be a problem that
           (it correctly fills just one buffer when it needs more)
KittyCat>  s/across/times/
vknecht>   avacore told me that according to some doc, that number would be a number of frames
vknecht>   I personnally didn't really check that yet
KittyCat>  alBufferData takes the number of bytes (though it seems the code assumes its bytes already)
KittyCat>  if it was frames, though, I don't see why any number would work
KittyCat>  as long as length1 and length2 are properly set, and they're of sufficient size, it should be fine
KittyCat>  do you know how often PerformUpdate is called?
vknecht>   no, but it seems to be a critical question
vknecht>   it may be frame-drawing (fps) dependent
KittyCat>  I can't see anything wrong with it, but the way it unqueues and refills buffers is kind of odd to me.
KittyCat>  could also be a general performance thing, if this stuff is done asyncronously
vknecht>   ok; well, if you don't have any problem with that, I'll paste or link to this irc log in CS' Trac/wiki,
           and have avacore check it, since I don't know all ins and outs enough
KittyCat>  if CS could differentiate between static sounds and streaming sounds
           (instead of assuming everything is streaming), that would help narrow it down
vknecht>   hopefuly, he'll be able to correct stuff, or maybe come here and discuss more about
KittyCat>  sure, I have no problems with that