2011/10/29 Wang Xingchao <wangxingchao2011 at gmail.com>: > 2011/10/29 Maarten Bosmans <mkbosmans at gmail.com>: >> --- >> ?src/.gitignore ? ? ? ? ?| ? 61 +++++++++++----------- >> ?src/Makefile.am ? ? ? ? | ? 10 ++-- >> ?src/tests/voltest.c ? ? | ?134 ----------------------------------------------- >> ?src/tests/volume-test.c | ?134 +++++++++++++++++++++++++++++++++++++++++++++++ >> ?4 files changed, 170 insertions(+), 169 deletions(-) >> > > make sense for me. this tool is very useful to check soft volume > optimization. Only one comment about the timestamp before/after the > test, i am afraid it become inaccurate if system in high overload, > pa_rtclock_now() will think over sleep/interrupt time of current. Note that this is not the same test you used earlier from my orcify branch, that test is called svolume-test. This is an existing test that only checks calculations on the volume variables, not on how that volume value is applied to actual audio samples. As such, volume-test does not use pa_rtclock_now or any timing related functions. In general you're right that for performance measures the wall clock time is not ideal. But on the other hand, performance test should always be done with an otherwise idle system, so definitely browsers, etc. closed. In these cases the wall clock time is pretty reliable. That's why in some tests the standard deviation of the timing measurements is printed. If the wall clock time measurements are reasonably close together, you know that no external program is interfering with the measurements. Note that CPU time measurements are no help either when the system is otherwise loaded. The actual CPU time for other programs does not matter then, but you'll always see cache effects, so having an idle system is needed either way. Maarten