On Tue, 2004-09-07 at 19:14, Malcolm Baldridge wrote:
Now that the
final touches are being put on the 2.6 low latency patches,
a massive migration of linux audio users to 2.6 is imminent.
Really? Is this even wise or safe?
Once people see how much better it works than 2.4+ll there will be no
stopping it.
It looks like things have barely gotten to the
"It seems to work" stage, let
alone made it through the "It doesn't crash too often" or "I
haven't lost
data with it lately" stages of validation.
It has been working perfectly for me for weeks now.
There's nothing in 2.6 that's required for a
reliably running 2.4-based
setup.
Unless you have new hardware that isn't supported by 2.4. Or need lower
latency than 2.4 can provide.
If Linux Audio users are interested in actual
recording and music
production, I think you might be better off steering them towards a known
safe and proven solution, rather than a series of patches which are still
steaming from their maker's keyboard.
I never said the 2.6 low latency patches were ready for general use. In
fact I have said exactly the above in several previous posts.
It's easy to mistake the rapid pace of linux
kernel development and
translate for actual "release grade" software, but this is a dangerous
fallacy. A newbie user is the worst beta-tester for this kind of maverick
kernel which has not received even a month of hardcore stress-testing and
the time for it to percolate to a large number of systems out there in
linux-land.
Um, this is exactly what I said in my response to the 2.6 low latency
thread. If you read my post I said that unless you enjoy patching and
recompiling your kernel and living on the bleeding edge in general that
you should wait for binary kernel packages for your distro.
Anyway if the
author does not object, I would be willing to spearhead a
drive to get this into the kernel. I am sure they will approve as soon
as 100s linux audio users voice their approval...
Good luck. Generally, the Linux Kernel maintainers tend to focus on the
patch and what it does to the kernel rather than take a popularity poll for
its introduction.
The realtime-lsm module is ~200 lines of code. What is does to the
kernel can be summed up in one sentence.
Robert Love was successful in getting the
preemptible
stuff into 2.6 because his patches were generally clean and separable. They
leverage already-existing locking code for SMP and enlarged their scope to
preemption, so there was very little messing around with drivers, and the
rules for kernel locking didn't change. Generally, if it was an issue for
SMP, it was an issue for preemption.
Um, please reread my original post. It looks like you only read the
first few lines. I am not talking about getting voluntary-preemption in
the kernel, I am talking about the realtime-lsm module.
Besides, your next paragraph clearly shows that you don't follow kernel
development at all. Please don't try to tell me how kernel development
works, it just makes you look clueless.
I have not looked through all of Ingo's voluntary
preemption patch, and
while I applaud his efforts towards reducing latency within the 2.6 branch,
I sincerely hope his approach isn't one of "sprinkle code and pray". I
would rather see latency issues be resolved by an intelligent re-design of
the kernel which is causing the problem rather than just band-aiding it with
schedule()'s sprinkled willy-nilly all over the kernel.
Please RTFS before you assume things like this, or at least read the
freaking LKML threads. This is exactly what has been achieved.
Did you just read that kernel traffic summary that was posted to
linux-audio-user? That information is all at least a month old, a LOT
has happened since then. Please know what you are talking about next
time.
Lee