[ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster

[SourceForge.net]

Bugs item #1501330, was opened at 2006-06-05 20:23
Message generated for change (Comment added) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Greg Ward (gward)
Summary: failure of test_ossaudiodev; elapsed time .1 sec faster

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Greg Ward (gward)
Date: 2006-06-11 12:54

Message:
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.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-07 09:04

Message:
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.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470