[Openal] Building OpenAL on older (RH7.3) linux?

[David Chait]

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).

Thanks,
-d

----- 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 
> linux.
>
> 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? ;)
>
> -d
>
> ----- 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/
>