2011/10/29 Maarten Bosmans <mkbosmans at gmail.com>: > 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. > thanks for clarification, i misunderstand it as the same tool at first glance. :) > 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. yes, that's reasonable. >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. > thanks for the info. --xingchao
