[PATCH 4/6] tests: Rename voltest to volume-test

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux