Re: [linux-audio-user] clicks and pops

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] clicks and pops
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.Stanford.EDU)
Date: Wed Nov 20 2002 - 09:20:17 EET

> Yeah, more and more I think the real culprit is Redhat 8.0, I was using
> 7.3 and had both my systems set for low latency with the 2.4.19 kernel, I
> think its the ol' blue curve, it could possibly be the cd, but the
> frequncy of over runs I'm getting is really bad, like one every two
> seconds.

YMMV. As an example I switched from 7.3 to 8.0 in my laptop and 8.0 is
MUCH better.

[pause for effect :-]

Ha! But that is not the whole story, there is a small difference, 8.0 is
on a new disk (IBM), 7.3 is on the original disk (Toshiba). The disk
seems to have made a BIG difference. The latency problems I was having
before are just gone (that does not mean I have _no_ latency glitches, I
still see them occasionally).

On both I have all the cdrom automount stuff turned off, same kernel,
same tuning. Just different disks (and versions of the os). On 8.0 I am
running gnome and metacity with the default theme. On 7.3 it was gnome
and sawfish.

I'm perplexed by the big difference in low latency performance between
different desktops and window managers that users see (I'm _not_ saying
that they do not exist!). I can see that one would use a lot more memory
than another, or have fancier screen rendering and thus eat more cpu.
None of those differences should produce latency hits for processes
running with SCHED_FIFO priority (as critical audio apps should). More
memory usage would increase disk activity through paging but that is no
different than any other disk activity (hmmm, maybe not at the kernel
level?) and if that is a problem (disk activity) then we are dead
anyway. More cpu usage would mean more contention for the processor, but
again that should not affect a SCHED_FIFO process (because it has
priority over all normal processes) and cause more dropouts. Overall,
non-SCHED_FIFO processes should slow down a lot for resource hungry
window managers (ie: the machine should "feel" slower) BUT that should
not produce more dropouts at all, provided that there is actually enough
cpu horsepower to fuel the realtime task.

After all, the window manager is just another user level program running
in the SCHED_OTHER priority ring (or so I would hope).

But apparently there _is_ a difference. So the question is: is there
anything different that the window manager is doing? (compared to other
programs). If there is (one example is trying to find out if there is a
cdrom in the drive), then that would highlight an area where the low
latency patches are currently lacking. If there is no difference, then
somehow the scheduler is not running the SCHED_FIFO task when it should.
I do remember running a SCHED_FIFO process in an old 2.2 low latency
patched kernel and doing sound synthesis while whatching the mouse and
the screen slow down, panes being slowly repainted (as I incremented the
system load) while the audio task kept going and going without a glitch.
It does not look to me like this is a window manager problem, it is a
kernel or driver problem being triggered by high resource usage. Not the
same thing. Changing window managers or whatever just eases up resource
usage enough so that things appear to work. Of course only right till
concert time when Murphy strikes again :-)

-- Fernando

New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 20 2002 - 09:19:51 EET