Re: [ecasound] WOW LOOK AT HESE PATCHES!

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] WOW LOOK AT HESE PATCHES!
From: Kai Vehmanen (kaiv@wakkanet.fi)
Date: Sun Nov 07 1999 - 03:39:12 EET


On Thu, 4 Nov 1999, Jeremy Hall wrote:

> on 2.2.13, and reading through LOTS of linux-kernel mail, it grew in my
> absance.
[...]
> [jhall@neserve0.corp.us.uu.net(tcsh):148] pwd
> /homes/norge/eng/jhall/Mail
> [jhall@neserve0.corp.us.uu.net(tcsh):149] ls -l linux-kernel
> -rw-r--r-- 1 jhall 95252201 Nov 4 09:06 linux-kernel

:) Nowadays I prefer to just read the Kernel Traffic issues
(http://kt.linuxcare.com/latest.html). linux-kernel itself is
too busy for my taste (and to my 14.4 modem :)).

> I read all about Mingo's patches and how they supposidly fixed tons of
> problems. I tore out the serial and video patches because his patch was
> made before the FB rework and I don't understand what the rework does.
> After recompiling, my machine can now happily run update to its heart's
> content without interrupting audio. I wonder what does this do to

Yes, for the last couple months, people have kept on raving about
these patches on the linux-audio-dev mailing list. A lot of
linux-audio people have tested them and results have been unbelievably
good. If Linus accepts these patches to 2.4 (Mingo is quite sure about
this), it will make Linux ideal for audio apps.

Basicly these patches just add sched_yield calls to various
problematic (=steel too much cpu-time) system calls. This way,
if program is run with realtime scheduling priority, it will
cpu-time without big brakes (<1ms according to some people).
With current stable kernels (2.2 and older) disk activity and other
such activities can cause noticable (>5ms) dropouts. Linus doesn't
like Mingo's original patches, because he (and many others) think that
these big routines should be rewritten. Just adding schedule calls
is avoiding the real problems.

> ecasound when multitrack recording? I haven't tried recording yet with it,
> but I am seeing improvements on the speed with which data is digitized and
> retransmitted on the ethernet.

Basicly all realtime apps (like ecasound) should perform better with
these patches. Ecasound doesn't currently run with rt-priority,
but I'll change this if the patches are accepted. Ecasound won't be
able to handle more data, but it will be more stable&robust (other apps
aren't able to cause dropouts). I haven't yet had time to test these
patches myself, so this is all just speculation, but I'm pretty sure
about this.

--
Kai Vehmanen <kaiv@wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav
 . http://www.wakkanet.fi/kerttulin_listat/ - music&movies (in Finnish)


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2a24 : Sun Nov 07 1999 - 12:04:54 EET