[Openal] Second Life and 1.9.563

[Tom Porter]

Thanks for the feedback.  Now that you mention it, I do think that  
SL's media streams are handled via Gstreamer.  I had forgotten about  
that since I haven't actually built SL, just use the pre-built  
versions.  I'm not sure now how voice is output.  The streams for  
those various things show up in PA Manager, but that is probably  
because whatever layer they go through ultimately ends up using Pulse.

The biggest reason I don't use the ALSA plugin with Pulse is because  
it CPU usage spikes for Pulse.  There are some issues there such that  
I can't really even run SL with audio that way.

I am not all that familiar with GIT (more a CVS guy), but I believe  
your tutorial will help.  It is basically the same thing I was going  
to do manually.  'Divide and conquer' as it were.  I'll give it a try  
and post my findings.

Thanks,
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.