29 May
2003
29 May
'03
8:35 p.m.
I'm a little green at time measurement facilities available in linux,
In my host, I would like to be able to measure how much time each
individual LADPSA plugin takes. Assuming I do realtime work with the
smallest buffer sizes my system can handle, what options are available
to me to measure time on this small scale? I know that the typical
system calls time and gettimeofday have resolution of 10 ms, which is
too big for this purpose. Is there any way to do this? Is there a
high-res time howto?
-jacob robbins.....
29 May
29 May
8:58 p.m.
"jacob robbins" <jrobbins(a)newyorkmusicunion.com> writes:
I'm a little green at time measurement facilities
available in linux,
In my host, I would like to be able to measure how much time each
individual LADPSA plugin takes. Assuming I do realtime work with the
smallest buffer sizes my system can handle, what options are available
to me to measure time on this small scale? I know that the typical
system calls time and gettimeofday have resolution of 10 ms, which is
too big for this purpose. Is there any way to do this? Is there a
high-res time howto?
I've been using jack_frame_time() for tracing audio threads in a JACK
client. It works quite well. Basically you get a running frame
counter (unsigned long) which can be used to compute the difference
from an earlier measurement. The resolution depends on the JACK
sample rate, which is typically either 1/48000 sec or 1/44100 sec.
If you're using JACK anyway, this is an easy solution.
There are lots of other facilities available. I'm sure others will
explain their advantages and disadvantages. :-)
--
Jack O'Quin
Austin, Texas, USA
9:12 p.m.
In my host, I would like to be able to measure how
much time each
individual LADPSA plugin takes. Assuming I do realtime work with the
smallest buffer sizes my system can handle, what options are available
to me to measure time on this small scale? I know that the typical
system calls time and gettimeofday have resolution of 10 ms, which is
no, gettimeofday() has microsecond resolution. on a PII-450, it takes
about 60usec to call gettimeofday(), and about 12usec to execute
inline code to read the cycle counter and then divide by a
pre-established CPU MHz. its really a lot simpler to use
getttimeofday(), but JACK (http://jackit.sf.net/) has generic code to
read the cycle timer and figure out the CPU MHz if you want to go down
that path.
too big for this purpose. Is there any way to do this?
Is there a
high-res time howto?
no howto. most kernel people try to discourage it with claims about
unreliability.
9:45 p.m.
On Thu, 2003-05-29 at 15:23, jacob robbins wrote:
I'm a little green at time measurement facilities
available in linux,
In my host, I would like to be able to measure how much time each
individual LADPSA plugin takes. Assuming I do realtime work with the
smallest buffer sizes my system can handle, what options are available
to me to measure time on this small scale? I know that the typical
system calls time and gettimeofday have resolution of 10 ms, which is
too big for this purpose. Is there any way to do this? Is there a
high-res time howto?
The Pentium Time Stamp Counter is often used for this purpose. It can be
found in Intel and compatible CPUs from Pentium on up. The rdtsc
assembler command is usually used for this purpose which reads the
elapsed CPU cycles, giving you a resolution of 1/CPU_MHz of second
resolution (not including the overhead of the rdtsc and other
instructions for processing its value). A function like:
void rdtsc(unsigned int *lsi, unsigned int *msi)
{
__asm__ ("rdtsc" : "=a" (*lsi), "=d" (*msi));
}
will fetch the time stamp counter into two 32 bit integers, lsi will be
the least significant integer, msi will be the most significant.
-jacob robbins.....
The lowlatency utility and FluidSynth are a couple of programs that have
code that uses this. Cheers.
Josh Green
6:45 a.m.
On Thu, May 29, 2003 at 04:23:48 -0600, jacob robbins wrote:
I'm a little green at time measurement facilities
available in linux,
In my host, I would like to be able to measure how much time each
individual LADPSA plugin takes. Assuming I do realtime work with the
smallest buffer sizes my system can handle, what options are available
to me to measure time on this small scale? I know that the typical
system calls time and gettimeofday have resolution of 10 ms, which is
too big for this purpose. Is there any way to do this? Is there a
high-res time howto?
I have a patched version of applyplugin that does this, mail me offlist if
you want it.
- Steve
7840
days inactive
7841
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Jack O'Quin -
jacob robbins -
Josh Green -
Paul Davis -
Steve Harris