Re: [linux-audio-user] Gnome/Alsa installation?

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

Subject: Re: [linux-audio-user] Gnome/Alsa installation?
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.Stanford.EDU)
Date: Fri Aug 23 2002 - 10:15:14 EEST


> begin Fernando Pablo Lopez-Lezcano <nando_AT_ccrma.Stanford.EDU>
> > But the kernel RedHat distributes is not plain vanilla Linus,
>
> true. IIRC, redhat uses the ac patched kernels. oddly enough, the ac
> kernels have slower, older VM subsystems. apparently, alan cox didn't
> think the andrea VM system was tested enough to be put into stable
> kernels.

Probably. It does not only include -ac but other patches as well. At some
point I was trying to base my kernels on theirs but I gave up, too much
stuff to track. I do use their spec file and build process.

> good and bad, just like everything in life. :-)

Yup...

> > it has literally hundreds of patches. _Some_ of the patches are
> > additional drivers that were not (at the time of the build and
> > testing process, I guess) part of the standard Linus kernel.
> > So maybe it has more. Then again, maybe it has less if some of
> > them were not configured to build. Either way it is not going
> > to be a big difference (unless you happen to own hardware that
> > needs a specific driver and either plain Linus or RedHat
> > kernels don't have it :-)
> >
> > [I don't presonally use RedHat's default kernel but a plain
> > Linus with capabilities, preempt and lowlat added]
>
> fernando, i wouldn't cry if you posted your opinions and observations
> about these patches. i haven't tried them myself, but i'd like to.
> have you done any stress testing with them?

Not really (I mean under controlled conditions). They are being actively
used in about 40 machines and they seem to do just fine.

> have you noticed any real gains?

Yes, of course. A plain Linus kernel without any low latency tweaking will
definitely cause under/overruns while playing or recording with short
latencies. Switching windows, disk activity, even mouse movements under
some conditions will break playback or recording. If you are not
interested in low latency work then incresing the size of the audio
buffers will solve the problem, but they have to be pretty big...

The Andrew Morton low latency patch makes the most difference by far. It
is very effective (there is a latencytest program I use to check latencies
and see what happens with different combinations). There are a couple of
addons to it (from Jussi Lako) that I found necessary to be able to use
the DRI video interface without latency hits.

The preemptible kernel patch supposedly increases the responsivenes of the
whole system, but I have not done any measurements, and on fast computers
it does not seem to make a big difference. But it does not seem to hurt
either :-) It has a companion patch (lock-break) that does the same thing
(conceptually) as the AM lowlat patch but touches less high latency
points so it is less effective.

The capabilities patch does not affect performance, it just enables a
normal user to start processes that run with RT_FIFO priority with the
proper software (for example the jack server can be started by a non-root
user with a small suid program if the kernel has capabilities enabled).

All this is in vain if you do not tune your EIDE hard disks and cdroms to
use dma (first) and possible unmask interrupts (helps a bit more).

Anyway, even with all the patches in place and with all tuning done, the
actual performance you get depends on the kernel drivers you are using.
Most common hardware is fine and you can get down to really low latencies.
For example, I have an IDE RAID controller that is introducing peaks in
the 8 to 19 mSecs range. Or a laptop where (just a guess) the acpi patch
it needs introduces 170mSec glitches every once in a while :-( If the
driver for the particular hardware you are using is not well behaved then
you are out of luck until a guru takes it apart and fixes the problems -
BTW, no, I'm not one :-)

There is not yet (I think) a general awareness on the part of the kernel
hackers that low overall latencies are necessary, so the priority is not
there yet to write the software in a way that it is inherently low
latency. It is not surprising given the use most of the linux boxes get.
When more linux workstations start being used for low latency work things
may change (and the awareness _has_ already changed for the better in the
last couple of years).

Anyway, I don't want to sound discouraging, the overall situation is
pretty good. With off the shelf hardware you can get very very decent
performance on a system that is very stable. Not bad at all.

-- Fernando


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

This archive was generated by hypermail 2b28 : Fri Aug 23 2002 - 10:11:59 EEST