I am getting a consistent failure of test_ossaudiodev
on Ubuntu Hoary on an HP xw4300 Workstation.  The
failure is that the test is printing out "elapsed time:
3.0 sec" while the test expects 3.1 sec.

I don't know anything about sound recordings so I don't
know if there is any way to calculate the expected
length of the test sound file and thus know that this
is a true error or the test is just working faster than
normally expected.

Logged In: YES 
user_id=11375

Yes, the length is calculable -- you have N bytes in the
file, with so many bits per sample and so many samples per
second.  Perhaps the driver now buffers more and the write()
returns earlier?  Or you could try printing the exact
duration without rounding; maybe it's 3.0999999 or something
and the print is just truncating.


Assigning to Greg Ward, in case he gets around to looking at it.

Logged In: YES 
user_id=14422

Brett -- I'm not sure why I put 3.1 sec in there.  It's
probably just what popped out the first time I ran this test
on my machine.  Anyways, simple math reveals that the
theoretical running time of the test file is ~2.93 sec:

  (23493 bytes) / (1 byte/sample) / (8000 samples/sec) =
2.93 sec

which of course ignores the overhead of the file header, but
that seems to pretty small.  "sox" agrees:

$ time /usr/bin/play Lib/test/audiotest.au

Input Filename : Lib/test/audiotest.au
Sample Size    : 8-bits
Sample Encoding: u-law
Channels       : 1
Sample Rate    : 8000

Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output
Buffer:  23.46K

Done.
/usr/bin/play Lib/test/audiotest.au  0.03s user 0.02s system
1% cpu 3.127 total

Can you try that on your machine and put the output here?

Anyways, the likely culprits are 1) faster hardware (less
overhead opening audio device, reading file, etc) and 2)
variations in sound chip frequency (8000 Hz is not always
exactly 8000 Hz).  I'll try to fix the test so it's a little
fuzzier.

Logged In: YES 
user_id=357491

Output with the patch:

playing test sound file (expected running time: 2.93 sec)
actual running time was 3.09 sec (5.5% difference)

Logged In: YES 
user_id=14422

Fixed in r50775 using the patch I attached earlier.