[sldev] How to solve this bug?

[Aleric Inglewood]

I think I finally figured out what caused the slow FPS (in my case).
I created a new jira for this because it is impossible to know
(from the data provided by others) if they are suffering from the
same problem, or that their problem is (totally) different.

jira: http://jira.secondlife.com/browse/VWR-14914

To summarize the problem in this mail:

* Viewer often works OK (I have FPS up to 80 at time, when
  looking at nothing; or 30 when looking at -say- my house).

* Sometimes the FPS drops dramatically. This can be anywhere
  between 0.3 and -say- 4 or 5, but I after my investigation
  my conclusion is that this bug/problem could in principle
  cause any delay (ie, a drop from 30 to 20, or 10).

My conclusions so far are as follows:

* The FPS drops because the main thread is waiting for a lock
  inside the libopenal library with increasing times up till
  an average of 0.2 seconds (sometimes less sometimes more),
  and several/many such calls are being made per frame.
  This happens, obviously, during calls to libopenal (in
  indra/llaudio/audioengine_openal.cpp).

* The reason it cannot obtain the lock quickly, while normally
  it can, is because the lock is being help almost 100% of
  the time by the audio thread, and although the audio thread
  is not holding the lock for more than 400 microseconds at
  a time, it is *immediately* taking the lock again without
  calling a cancelation functions (or so is my guess), therefore
  not giving other threads the chance to 'take over'. At any
  rate it is clear that the audio thread had become so busy
  with "mixing" the audio channels that it stops waiting
  between releasing the lock and obtaining it again, making
  it very hard for the main thread to get the lock.

To understand this in more detail, here is how the audio
thread works:

* The audio thread runs entirely inside libopenal.
  It loops, normally waiting for the sound card to have
  digested the last sound batch, and when the buffer
  is empty enough (but hopefully not entirely empty yet)
  it calls aluMixData which locks the audio context object
  and starts adding up all audio channels.

* Normally aluMixData is called 2757 times per second,
  this probably has to do with the number of samples
  per second in the audio used (so, it's stable).

* Mixing channels takes about 10 microseconds per channel
  (on my machine, with a custom libopenal compiled without
  optimization; but the bug is the same thing with different
  figures, so lets just use this as example).