[Openal] Building OpenAL on older (RH7.3) linux?
davebytes at comcast.net
Tue Aug 30 12:58:21 PDT 2005
Further leads for anyone who has more of a clue than I:
If I disable calls to set alSource3f(source, AL_POSITION, ...) -- and to
AL_VELOCITY -- the problems all go away. Just played an entire deathmatch
round with tons of sound effects going on, no problems I could tell.
That would seem to indicate an issue with, what, doppler stuff kicking in or
something?? Since I had varying problems from really slow to really fast,
after disabling tons of calls, trying other things, made sense that a
doppler-shift working erroneously would cause those results.
Even with AL_VELOCITY calls off, if I turn on just AL_POSITION updates on
sources, everything goes all chipmunk again.
Also, the code I'm using currently creates and destroys sources on-the-fly
for every sound play/stop pair. At some point, I thought I read that wasn't
a good thing, better to pre-allocate sources up front. Of course, I tried
pre-allocating, but then I seem to get no audio whatsoever (I'm allocating
32 sources, figure that'd be a safe/sane number).
----- Original Message -----
From: "David Chait" <davebytes at comcast.net>
To: <openal at opensource.creative.com>
Sent: Tuesday, August 30, 2005 12:45 PM
Subject: Re: [Openal] Building OpenAL on older (RH7.3) linux?
> Okay... With updated autoconf/automake, I can build both HEAD and 1.0
> BUT, while most of the tests seem to work fine, in actual use (this is a
> commercial engine, has worked on linux prior, thus might be my machine or
> something in my build/headers/etc...) I'm getting results where the sound
> files are being played back either heavily slowed down (the original
> pre-built openal binary I was given), or really sped up (libopenal, both
> HEAD and 1.0linux self-built).
> This is code that in theory should all just be working (and should have
> even with the prebuilt binary), so I'm wondering if it has to do with a
> particular sound device being grabbed by default that isn't always playing
> nice. Don't know if there's a way I should 'force' the code to start with
> OSS as default or something.
> I've tried 11, 22, and 44KHz master contexts, and the files being played
> are all over (generally mono, 8/11, 8/22, 16/22...).
> I've tried forcing sane defaults myself for stuff like pitch (which is
> what this would seem like). I've also done some rudimentary debugging to
> validate that the alBufferData is seemingly being passed valid values.
> I haven't looked at potential alErrors as yet (I think the code checked in
> major locations, but not necessarily minor ones...).
> Thoughts, ideas, snippets, directions, Bueller? ;)
> ----- Original Message -----
> Jason Daly wrote:
>> David Chait wrote:
>>> I'm assuming the older autoconf is screwing stuff up. I get:
>>> # sh ./autogen.sh
>>> /usr/bin/m4: configure.in: No such file or directory
>>> autoconf: configure.in: No such file or directory
>>> Any help would be appreciated... I've got a prebuilt AL lib that is
>>> giving me distorted audio playback (like playing back at 1/10th speed),
>>> sound dropouts (as if sound plays are failing for weird reasons), etc.,
>>> and would like to try with a source-built lib so I know what the
>>> codepaths look like and can add in some printf-debugging... Thanks!
>> You'll probably need autoconf 2.53 or later and automake 1.6 or later for
>> the newer OpenAL build system. You can either look for rpm updates at
>> http://fedoralegacy.org/download/ (they support Red Hat 7.3) or get the
>> source code from http://directory.fsf.org/devel/build/
More information about the Openal