OpenAL flames, was Re: [SDL] I need input for an article on SDL

Bob Pendleton bob at
Thu Jul 11 13:52:00 PDT 2002

Please change the title when you change the subject.

		Bob Pendleton

Joseph Carter wrote:
> On Wed, Jul 10, 2002 at 11:43:06PM -0700, jvalenzu at wrote:
>> > > I hate pointing it out but gaming on linux is a margin market anyway.
>> > > I doubt you're serious about addressing what support for "3D sound
>> > > features" but I can say that having a solid software renderer was and
>> > > is my goal with the linux reference implementation.
>> > 
>> > Great - if you want a 3D sound API for two speaker systems.  Meanwhile, 4
>> > and even 6 speakers are supported by several drivers now.
>>Guess what.  4 speaker sound is supported by linux openal, via
>>extension ( I'd like to take the moment to credit Chris Purnell
>>for this and several other excellent patches.  He was criminally
>>removed from the CREDITS file during the various cvs root changes
>>but has been re-added ).
> Then I apologize for not noticing this.  I know about Chris's work on
> OpenAL, but did not see him mentioned anywhere.  Much of my annoyance with
> the Creative/Loki tree was that it did not use Chris's bugfixes or his
> four-speaker support - he had tried to get his changes into Loki's tree
> earlier.  I can guess then that his changes were incorporated into the
> short-lived icculus tree?
>>  API Information.  Daily snapshot.  Were you really
>>confused?  You were even provided a link.  I'd say you failed to
>>provide a cursory effort.
>> > The website ( refers back to the CVS.  There
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I'd say you failed to read my message before you started flaming.  That
> _IS_ the API information link you accuse me of failing to go to.
>> > are SGML docs, but these total a mere 7300 lines total for the entire
>> > library, in pretty-printed SGML source code.  How you document 15 megs of
>> > source code completely or thoroughly in 7300 lines of mostly markup is
>> > beyond me.  I know enough to write a simple mixer able to handle 8 sounds
>> > for two channels with independant volume and attenuation, but I can't
>> > follow what is in the documentation directory.
>>Indeed, if you claimed to be able to follow what was in a documentation
>>directory I'd be very surprised.  You've shown no ability so far.
> You've shown no consideration of the possibility that the documentation
> could somehow be confusing, possibly incomplete, or otherwise in need of
> correction.  You refuse to even consider the concept that the README needs
> an update to actually point someone to real documentation rather than a
> pointer to a pointer to a page which says the documentation is in CVS
> (which it is, if you can follow it..)
>>The documentation is available in HTML for those of us who have
>>never been able to get SGML to work ( sadly guilty of that myself
>>).  Annotated versions are included to determine reasoning behind
>>api decisions.
> You'd rather assume that I haven't even seen the SGML (I had not seen the
> HTML, but I find it now that I know the link "daily snapshot" has nothing
> to do with CVS..)  I can read the SGML just fine.  Follow what I'm reading
> though?  That I could not do so well.  I'll go back and read that chapter
> of John's book again though, it's been more than a year since I actually
> tried to use OpenAL in a serious application.
> I still believe the SGML documentation (which includes everything the
> annotated HTML docs include - I've checked) is not very clear, and is
> missing fundamental concepts.  That or there's something I Just Don't
> Understand about the API.  In either case, I think it could stand to be
> improved.
>>And I can point out that each api decision was open to public
>>discussion, with requests for comments.  Several comments lead to
>>major changes in the API.  This contrasts with the process for
>>other open source libraries, which have had less public comment or
>>insight into their design.  The effort that Bernd committed to the
>>design of the API - including soliciting comments, questions,
>>suggestions from potential users - was beyond reproach.
> I do not question these practices.  I stayed out of the discussions
> because I knew very little about sound coding at the time.  I know enough
> to mix sixteen sources with volume and attenuation to stereo sources now,
> but don't claim to actually be much of a sound person.  I can do this
> because I've seen and understand code which does this, and could reproduce
> it, not because I have any fundamental understanding of sound processing.
> Maybe I haven't got the background to use OpenAL then, but I certainly had
> less background in graphics when I started learning OpenGL.  I'd expect a
> similar learning curve.
>> > Does the word "bloat" mean anything to you?  It'd be one thing if we were
>> > talking about hardware acceleration here, but we're talking about extra
>> > dependencies on half a dozen libraries to add support for mp3 and vorbis
>> > in software as part of the reference implementation.  OpenGL is useful
>> > because it is simple, well documented, and reasonably self-contained.  So
>> > far, OpenAL is none of these things!  In fact, the package available for
>> > my dist depends on libaudiofile, libesd, SDL, SMPEG, and libvorbis.
>>The extensions are entirely modular, so bloat is a red herring.
>>The dependencies are on a per-extension basis - so if you don't
>>want to install libvorbis, libaudiofile, libesd arts or whatever,
>>don't enable the extension.  I've never really understood the
>>philosophy that code reuse is bad anyway.  What's the alternative?
>>Put an entire copy of smpeg and libvorbis into openal?  Just so
>>people don't have to type --enable-smpeg?  I don't have any interest
>>in maintaining an mp3 decoder.
> The mp3 decoder should be my problem to worry about, not yours.  If I want
> mp3, I would have to worry about which decoder to use, whether or not I
> wanted it static or dynamic, whether I'd include it with my binaries for a
> given arch or not, etc.  I don't like external deps much, as list archives
> will plainly tell anyone.  I don't like them to the point that I wrote a
> whole mechanism to handle dynamic OpenGL binding to ensure that the
> program built regardless of how screwed up your vendor's OpenGL dev stuff
> is.
> I'd rather not have to do the same with OpenAL, especially given that
> currently SDL does not export the functions which are needed to do this
> from its API.  (They're trivial for Win32 and free UNIXes, but it's still
> better left to SDL for portability reasons..)  Kudos to whomever is
> responsible for making alcGetProcAddress be guaranteed to work on all
> functions, rather than just extensions as OpenGL.
>>And there's nothing stopping you from implementing your own decoders
>>for these formats.  Then you can sit in comfort and introduce the
>>exactly same dependencies you just eliminated by selecting a
>>configure option.  Yay!
> If I don't want them, I shouldn't have to worry about them.  I'm stuck
> worrying about them anyway.
>>I hope it's obvious by now that your criticism is based largely on
>>ignorance and misconception.  The API is simple, amply documented
>>and if it does not meet your criteria for self containment, at least
>>it is modular.  I guess it's lost on you that many of the extensions
>>are in alut, not al.
> My criticisms are based on what I can see in CVS and on the website.  I'm
> not infallible (I did not know that Chris's patches were finally accepted
> after more than a year of him maintaining a fork he didn't want, and I
> guess widespread Linux support will happen if widespread win32 support
> does) but simple and amply documented I still contest, if for no other
> reason than that if such were the case I should not have nearly as many
> problems trying to find out how to do anything useful with the library.

+ Bob Pendleton, an experienced C/C++/Java +
+ UNIX/Linux programmer, researcher, and   +
+ system architect, is seeking full time,  +
+ consulting, or contract employment.      +
+ Resume:        +
+ Email:  bob at                +

More information about the SDL mailing list