5 May
2006
5 May
'06
9:06 p.m.
After some discussions at LAC I think a user friendly latency tester is
needed so users have an easy way to test a setup, something better than
than just installing apps and being mystified when they get tons of
xruns.
The backend is trivial (there are a bunch of similar little tools out
there), but I'm not a GUI person. Would anyone like to help design and
implement this? Since time is money ;-) a simple Gnome and/or KDE front
end would be the easiest way to start, and of course there should be a
separation between the GUI and the back end so anyone can implement a
leaner version if they want to. Anyone want to help with the GUI side?
Lee
6 May
6 May
1:57 a.m.
On Saturday, 6. May 2006 01:06, Lee Revell wrote:
After some discussions at LAC I think a user friendly
latency tester is
needed so users have an easy way to test a setup, something better than
than just installing apps and being mystified when they get tons of
xruns.
I think that would be very useful. Exactly what kind of latencies would
this tool measure?
The backend is trivial (there are a bunch of similar
little tools out
there), but I'm not a GUI person. Would anyone like to help design and
implement this? Since time is money ;-) a simple Gnome and/or KDE
front end would be the easiest way to start, and of course there should
be a separation between the GUI and the back end so anyone can
implement a leaner version if they want to. Anyone want to help with
the GUI side?
To me the GUI appears a lot more trivial than the backend :) So I'd like
to offer my help writing a GTK frontend (steering clear of any particular
Gnome/KDE dependencies).
Are you going to make a fully functional command line version?
Dominic
2:19 a.m.
The backend is
trivial (there are a bunch of similar little tools out
there)
Are you going to make a fully functional command line version?
12:13 p.m.
On Sat, 2006-05-06 at 05:54 +0200, Dominic Sacré wrote:
I'd like to, this is why I said the GUI should be separate from the back
end.
I don't have the bandwidth to do the whole thing - I need someone (or a
few people) to make a mockup GUI and then I'll wire up the buttons.
Lee
On Saturday, 6. May 2006 01:06, Lee Revell wrote:
Same as the existing CLI tools - it would start an RT thread that polls
on the RTC, then tell the user to generate some load (switch windows, do
a find /, pingflood the default gateway, whatever), then report back the
maximum latency.
After some discussions at LAC I think a user
friendly latency tester is
needed so users have an easy way to test a setup, something better than
than just installing apps and being mystified when they get tons of
xruns.
I think that would be very useful. Exactly what kind of latencies would
this tool measure?
The backend is
trivial (there are a bunch of similar little tools out
there), but I'm not a GUI person. Would anyone like to help design and
implement this? Since time is money ;-) a simple Gnome and/or KDE
front end would be the easiest way to start, and of course there should
be a separation between the GUI and the back end so anyone can
implement a leaner version if they want to. Anyone want to help with
the GUI side?
To me the GUI appears a lot more trivial than the backend :) So I'd like
to offer my help writing a GTK frontend (steering clear of any particular
Gnome/KDE dependencies).
Are you going to make a fully functional command line version?
10:26 p.m.
On Saturday, 6. May 2006 16:13, Lee Revell wrote:
Could you give me some links to these tools? I know I've seen something
like this, but I'm unable to find it...
How do these tools relate to the latency tracer in the realtime kernel?
Dominic
I think that
would be very useful. Exactly what kind of latencies
would this tool measure?
Same as the existing CLI tools - it would start an RT thread that polls
on the RTC, then tell the user to generate some load (switch windows,
do a find /, pingflood the default gateway, whatever), then report back
the maximum latency.
10:35 p.m.
On Sun, 2006-05-07 at 02:25 +0200, Dominic Sacré wrote:
On Saturday, 6. May 2006 16:13, Lee Revell wrote:
Could you give me some links to these tools? I know I've seen something
like this, but I'm unable to find it...
I think Florian Schmidt's web site has the latest latency tester.
I think
that would be very useful. Exactly what kind of latencies
would this tool measure?
Same as the existing CLI tools - it would start an RT thread that polls
on the RTC, then tell the user to generate some load (switch windows,
do a find /, pingflood the default gateway, whatever), then report back
the maximum latency. How do these tools relate to the latency tracer in the
realtime kernel?
The tester is a userspace tool to measure low latency performance, the
latency tracer is an in-kernel mechanism to determine which part of the
kernel might be causing a latency problem.
Dominic
7 May
7 May
8:57 a.m.
On Sat, 06 May 2006 20:35:07 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
I think Florian Schmidt's web site has the latest latency tester.
You can get the tarball from this page:
http://tapas.affenbande.org/?page_id=15
[Some elaborations for the OP]:
Of course, as this uses the RTC and not the soundcard it cannot account
for i.e. buggy soundcard drivers [i have a cs46xx card that _always_
produces some xruns no matter how well tuned the system is. No such
problems with my delta 66].
I kinda thought rtc_wakeup was obsolete these days, as the kernel tools
are a much better instrument [assuming you use a -rt kernel, or does
vanilla have the latency tracing et. al. stuff these days, too?]. So
maybe it is still useful for a non-rt kernel. But what serious audio
user would use a non-rt kernel?
On a 2.6.15.4 kernel with low latency desktop setting [non-rt] i
get a max jitter of [after like 5 minutes running]:
new max. jitter: 68.4% (667 usec)
which looks pretty good. But it seems jackd has some more weak points
than rtc_wakeup [which is very simple]. For example on this kernel
running jack with a periodsize of 256 at a samplerate of 48khz _seems_
to run fine even with a find / or two. But beware. Copying large files
to /dev/null makes jackd sometimes produce xruns in the range of tens to
hundreds of ms -> ugh. rtc_wakeup OTOH is not affected by this. I
suspect the culprit is the FS [which jack depends on through its use of
pipes to do the interprocess wakeup]. But only -rt instruments could
tell us what's really up.
It seems -rt kernels have the latency tracing mechanisms available even
when not using full preemption. But i'm too lazy right now ;)
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Same as the existing CLI tools - it would start an RT
thread that polls
on the RTC, then tell the user to generate some load (switch windows,
do a find /, pingflood the default gateway, whatever), then report back
the maximum latency.
Could you give me some links to these tools? I know I've seen something
like this, but I'm unable to find it... How do these tools relate to the latency tracer
in the realtime kernel?
The tester is a userspace tool to measure low latency performance, the
latency tracer is an in-kernel mechanism to determine which part of the
kernel might be causing a latency problem.
11:22 a.m.
On Sun, 2006-05-07 at 12:56 +0200, Florian Paul Schmidt wrote:
I kinda thought rtc_wakeup was obsolete these days, as
the kernel
tools are a much better instrument [assuming you use a -rt kernel, or
does vanilla have the latency tracing et. al. stuff these days, too?].
So maybe it is still useful for a non-rt kernel. But what serious
audio user would use a non-rt kernel?
I think more will use the mainline kernel as it gets better (keyboard
players are perfectly fine with 5ms latency which mainline can certainly
deliver). And the latency tracer has overhead (if you oprofile it you
will see mcount() eats 1-2% of your CPU), and is complicated for users
who aren't linux experts to use.
We know the -rt kernel is OK for audio, but it would be nice to be able
to tell users "is this random kernel that I am running likely to be OK
for audio"
Lee
1:16 p.m.
On Sat, May 06, 2006 at 10:13:42AM -0400, Lee Revell wrote:
Same as the existing CLI tools - it would start an RT
thread that polls
on the RTC, then tell the user to generate some load (switch windows, do
a find /, pingflood the default gateway, whatever), then report back the
maximum latency.
In stead of telling the user to generate some (unpredictable) load I would
suggest re-using the parts from the alsa latency tester tool that automatically
spawn another process with a known load.
Just my 2 cents.
--
Martin
1:44 p.m.
On Sun, 2006-05-07 at 16:16 +0100, Martin Habets wrote:
On Sat, May 06, 2006 at 10:13:42AM -0400, Lee Revell
wrote:
Yeah I was thinking about this. There are workloads that cause xruns
(like display activity with some video drivers) that are hard to
simulate this way. Maybe we could generate some load and tell the user
to generate their own load at the same time.
Lee
Same as the existing CLI tools - it would start
an RT thread that polls
on the RTC, then tell the user to generate some load (switch windows, do
a find /, pingflood the default gateway, whatever), then report back the
maximum latency.
In stead of telling the user to generate some (unpredictable) load I would
suggest re-using the parts from the alsa latency tester tool that automatically
spawn another process with a known load.
6720
days inactive
6722
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
carmen -
Dominic Sacré -
Florian Paul Schmidt -
Lee Revell -
Martin Habets