No subject

time anymore to idle once it has to mix 1/2757 / 10*10^-6 =
36 channels. The maximum number of channels is 31, but
for some reason, during the bug, the time to mix the channels
is more like 20 microseconds. I did not investigate why
that is the case.

My conclusion is that it is "normal" for the audio thread
of have to mix 31 channels, which causes it to be so busy
that the main thread starts stalling, which you can see
in the frame console an increasing "audio" bar.

At some point it can become increasingly difficult for
the main thread to get the lock, causing it to stall longer
and longer up till 0.5 seconds (0.2 average) several times
per frame, causing an FPS as low as 0.3.

*************************************************************

As a side note, once my viewer gets into this state I cannot
get out of it anymore without a relog. My hypothesis is that
this is caused by two factors:

1) The number of audio channels is never decreased(!), not
   even after a teleport.

2) Once in this busy state, mixing a channel takes on average
   20 microseconds, so that it gets "sucked" into the state
   and won't fall out of it anymore.

The reason for point 1 is that an audio channel is
registered with libopenal when it is created, and never released
or removed anymore (imho, we're mixing silence in that case).

If some sound source gets out of range so that it stops playing
the source is marked as "not playing" but libopenal is still
mixing it. When a new source comes into range, a not-playing
source is REUSED. So, you will ONLY get more than (say) 20
sources when you visit a sim with 20 sources that are simultaneously
active (at 20 it starts to visibly delay my FPS), but you can
never get rid of them anymore; not even if you return to a sim
with just 4 sound sources.

*************************************************************

The question is: how to fix this problem?

There are a few options:

* Remove channels from libopenal when they are non-playing.

This wouldn't solve the problem, but at least you can recover
in that case by TP-ing or walking away from the many sound
sources.

* Do not call libopenal functions from the main thread.

This solution is my favourite, it would require a new thread
that handles the interface of LLAudioEngine: each of it's
virtual function will have to be changed to passing requests
to a queue of this new thread, which then will do the
actual call.

I'm sure I won't have problems coding this, but I want to
ask the list for their opinion before I start to implement
a change of this magnitude :)