[Openal] Second Life and 1.9.563

[Tom Porter]

Chris,

I did the regression testing you mentioned below and I found the first  
'bad' commit.  This is the output GIT provided.  I hope it helps.

bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358 is first bad commit
commit bdbdbcea26d4a12d4d3f76ad3724f2ad12a55358
Author: Chris Robinson <chris.kcat at gmail.com>
Date:   Wed Sep 23 01:24:10 2009 -0700

    Update in properly-sized chunks for PulseAudio

:040000 040000 d63bac4539b1f83dc462b55e09f443186afb3762  
8086d705d8feacc7b430070ff7cd6847414a0d08 M	Alc

If there is any other test or data I can provide, please let me know.

Tom Porter
thanatos at columbus.rr.com



On Oct 7, 2009, at 3:49 AM, Chris Robinson wrote:

> On Tuesday 06 October 2009 10:32:17 am Tom Porter wrote:
>> I believe the configuration I am using for SL allows everything to  
>> use
>> OpenAL.  The only real issue is the different between the version
>> releases of OpenAL Soft.  1.8.xxx works just fine for me and I can
>> continue to use it.
>
> I ask because, if the media/music stream is played out externally  
> (eg. through
> gstreamer's output sinks), then it might indicate a problem with  
> OpenAL Soft's
> PulseAudio backend. But if they play out the same OpenAL device, then
> PulseAudio is properly playing OpenAL Soft's mix and the problem is  
> elsewhere.
>
> If it's the latter case, then I'm stumped. Second Life  
> (v1.23.4.123908) is
> properly playing audio for me using the latest GIT of OpenAL Soft  
> (using ALSA
> output), and there isn't any change from 1.9 that would only affect  
> *some*
> sounds. Only thing to note is that on initial startup (before log  
> in), I don't
> get UI sounds right away. But after playing around in the  
> preferences for a
> little bit, or logging in, then I seem to get them.
>
>> Something changed in the 1.9.xxx release such
>> that it only partially works for me now.  I am not actually allowing
>> OpenAL to use the ALSA plugin for PulseAudio, but rather have OpenAL
>> configured to use the PulseAudio back end, directly.
>
> If it's a problem with 1.9's PulseAudio backend, using Pulse's ALSA  
> plugin may
> get around the issue. Although Pulse's ALSA plugin does have a bunch  
> of
> issues, any differences or lack of differences between the two  
> outputs may
> help me narrow down the issue.
>
>> If
>> I get the time, I may get the source from various places between the
>> releases and see if I can determine which changes caused this  
>> behavior.
>
> If you're familiar with GIT, it helps automate regression testing,  
> and keeps
> the number of rebuilds needed very low. Essentially, with GIT  
> installed you'd
> download the latest sources:
> $ git clone git://repo.or.cz/openal-soft.git openal-soft
> That will copy the repository into the openal-soft sub-directory.
>
> Then start a bisect and tell GIT the last known good commit (1.8's  
> release)
> and the first known bad commit (1.9's release):
> $ git bisect start
> $ git bisect good openal-soft-1.8.466
> $ git bisect bad openal-soft-1.9.563
>
> That will place the current head between the two releases. You would  
> then
> build and install the lib, try it with Second Life, then if it  
> works, run
> $ git bisect good
> or if it doesn't work, run
> $ git bisect bad
> or if a given commit doesn't build at all (or has another problem  
> preventing
> you from properly testing), run
> $ git bisect skip
>
> Keep testing and doing good/bad/skip until it tells you what the  
> first bad
> commit is. You should only need to do, at most, 10 tests given the  
> less than
> 100 commits between the two releases (probably closer to 6 or 7).
>
> When you get the first bad commit and are done bisecting, you can run
> $ git bisect reset
> to reset the tree back to its original head.