Test time spent sleeping

[Stefan Westerfeld <stefan space twc de>]

   Hi!

I've identified a problem in the audio test framework: for a standard test in
tests/audio, a lot of the time it takes to run the test is spent sleeping:

$ time make organsong-test
...
real    0m7.034s
user    0m2.032s
sys     0m0.200s
$ 

This seems to indicate that although only 2 seconds of CPU time are necessary
to run the test, it takes 7 seconds of real time. Why? I think the following
code is responsible:

static void
null_device_write (BsePcmHandle *handle,
                   const gfloat *values)
{
  NullHandle *null = (NullHandle*) handle;
  null->busy_us += handle->block_length * 1000000 / handle->mix_freq;
  if (null->busy_us >= 100 * 1000)
    {
      null->busy_us = 0;
      /* give cpu to other applications (we might run at nice level -20) */
      g_usleep (10 * 1000);
    }
}

Removing the g_usleep altogether in fact reduces the real time to run the test.
However, the funny thing (a side effect) is that without the g_usleep, the
output file grows a lot larger, because the end-of-song detection seems to take
a lot longer to detect that the song is actually over. So we get:

$ ls -l organsong-test.wav # with g_usleep
-rw-r--r-- 1 stefan stefan 8990764 11. Feb 21:04 organsong-test.wav
$ ls -l organsong-test.wav # without g_usleep
-rw-r--r-- 1 stefan stefan 21510188 11. Feb 21:13 organsong-test.wav

So I am not sure how to fix this side effect of removing the g_usleep yet,
maybe keep the g_usleep but make the time value dependant on the time elapsed
since the last sleep. However, a significant performance gain for audio tests
can be achieved by addressing this issue, so I think its a good idea to do
something about it:

$ time make slowcheck # with g_usleep

real    1m16.561s
user    0m35.642s
sys     0m4.544s

$ time make slowcheck # without g_usleep

real    0m34.342s
user    0m25.586s
sys     0m6.388s

So on my machine addressing this issue would make the audio tests run a little
more than twice as fast.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan