> 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? 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. There's nothing in 2.6 that's required for a reliably running 2.4-based setup. 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. 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. > 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. 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. 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. Cheers, =MB= -- A focus on Quality.
