Re: [linux-audio-dev] lowish-latency patch and toolchain

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

Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Khimenko Victor (khim_AT_sch57.msk.ru)
Date: Tue Jul 11 2000 - 08:32:30 EEST


In <20000711015337Z32702-532+22491_AT_nic.funet.fi> Juhana Sadeharju (kouhia_AT_nic.funet.fi) wrote:
>>From: "Khimenko Victor" <khim_AT_sch57.msk.ru>
>>> compilation option in Linux source tree, so that it comes with every
>>> Linux distribution. That would be __a real compromize__!
>>
>>Huh. You joking, right ? Low-latency patch was not accepted since it'll make
>>kernel maintainance nightmare (this not the only reason, but main reason).
>>And this patch as kernel compilation option will affect kernel maintainance
>>MORE not less then just patch without compilation option.

JS> Low-latency patch was not accepted as a patched patch -- put in to the
JS> kernel. I were talking about a separate patch file kept out of kernel
JS> but distributed with the kernel.

If it's just distributed with kernel but can not be cleanly applied then
what's the point ? And it can not be kept applyable without maintaining.

JS> But thanks for notifying it increases the maintaining.

JS> Well, I suggest we audio people maintain a separate patch against some
JS> up-to-date kernel. The rule "if it works, don't fix it" seems to apply
JS> perfectly to the Ingo's original patch.

May be. If you want some deep change like this included in kernel then better
start working on it when new development kernel is spawned, NOT when kernel is
in deep code-freeze and almost ready to go (Ok, 2.4 is not exactly "almost
ready to go" but it's in deep code freeze for sure).

JS> Now the latency jumped from 2.3 ms to 7 ms,

It can be expected. Instead of few dozends of pre-emption points there are
just six.

JS> and unless the situation doesn't change, we better move to the original
JS> patch.

If you need latency level of original Ingo patch, can not be satisfied with
anything worse then what all the fuzz was about ? It's perfactly clear that
now is WAY to late to do deep redesign of 2.4 subsystems to resolve problem
in sane way and Linus said quite definitely than he WILL NOT allow huge pile
of kludges like Ingo's patch to be applied. So it was quite obvious even before
petition was signed that you WILL NOT get 2.3 ms in your lab out of stock 2.4
kernel - no matter what, if and how: 2.3 ms was NEVER declared as starting
point for new patches; it's more like a goal. Ok, perhaps it was not 100%
clear - it was 99.999% clear or may be even 99.9% clear. It's now in more or
less the same state: may be there are some way to do it in acceptable for Linus
way but chances are slim, real slim.


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

This archive was generated by hypermail 2b28 : Tue Jul 11 2000 - 09:16:34 EEST