[sldev] How to solve this bug?
aleric.inglewood at gmail.com
Mon Aug 3 17:57:40 PDT 2009
On Fri, Jul 31, 2009 at 2:51 PM, Tofu Linden<tofu.linden at lindenlab.com> wrote:
> If I understand your description correctly -
> I think the bug is that OpenAL should NOT be mixing sources that are
> not in a playing state. That would be an AL bug (especially since
> sources are traditionally considered a 'cheap' resource in AL as
> long as they're not doing anything).
They are not doing that, I was counting the number of elements
in a linked list, but those sources that are non-playing are
skipped in that list and don't use CPU.
> Now, if we're leaving those sources in a playing state but just
> feeding silence into them - that would be a viewer bug.
This turns out to be the case. A muted sound is left playing
and it's gain is set to 0. Effectively this means that we're
mixing silence. In fact, it turns out to be a lot worse than
just mixing silence: libopenal for some reason uses 2 to 3
times more cpu to mix a channel that has it's gain set to 0,
than mixing one with a large gain!
The whole "intermittent" comes from the fact that I can
play 31 non-muted channels, but not 31 muted ones.
In the latter case the lock is hardly released by the audio
> I don't think that moving AL calls out of the main thread is
> the correct solution - (most) AL calls are not expected to significantly
> block in the first place, and this sounds like it is AL's own
> calls waiting for locks on AL's own backend. This would bite
> any AL-using app - this AL implementation should be fixed.
> I suggest investigating whether the viewer is doing the right thing
> (stopping non-playing sources) and if so, taking investigation over
> to the problematic AL implementation (openal-soft?).
I'd be happy, now that I know that mixing channels with a gain
of 0 cost much more cpu, to fix and close this bug by stopping sound
sources instead of setting their gain to 0.
More information about the SLDev