Messages in this thread | | | From | Juhana Sadeharju <> | Subject | Re: [linux-audio-dev] lowish-latency patch and toolchain | Date | Tue, 11 Jul 2000 12:30:30 +0300 |
| |
>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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |