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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
