Subject: Re: [linux-audio-dev] lowish-latency patch and toolchain
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Tue Jul 11 2000 - 12:30:30 EEST
>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).
Sorry, I wasn't talking about 2.4 or any else version. This is just
a problem which should be solved because nobody goes to RTLinux.
I'm waiting not only for the low-latency patch, but also for prioriticed
disks (filesystem?) so that audio/video application gets quaranteed bandwidth,
and also soft-RT support to XFree so that signal level meters and key
presses, for example, can get higher priority than any other X operation.
>If you need latency level of original Ingo patch, can not be satisfied with
>anything worse then what all the fuzz was about ?
The low-latency patch already worked in the main Linux. I were expecting
we are going to the same direction and not trying to get any "okay, here
is *this* patch for you, are you __happy__ now?!" compromize.
-*-
So, I'm not truelly looking for a quick solution as a simple patch.
More I would like solution in which kernel can be changed at run-time
similarly as scheduling policy is changed --- Ingo's patch changes
the kernel (and all its performances) for all which I find bad.
Since putting simple if's to the extra scheduling points is simply not
a good idea, would it give an opportunity to make larger parts of the
kernel changeable: a kernel section specially designed for audio/video
use.
Is there any webpage summarizing the other suggested solutions?
It was mentioned about some long-term solutions...
Regards,
Juhana
This archive was generated by hypermail 2b28 : Tue Jul 11 2000 - 13:45:41 EEST