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
