[linux-audio-user] realtime-lsm in the kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux