7 Sep
2004
7 Sep
'04
7:31 p.m.
Hey,
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. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Why make every user go through the extra step of downloading and
installing it? It's only a few hundred lines of code, and while I don't
consider myself a kernel expert I can grok it easily. I can't imagine
there would be much resistance, especially considering how much easier
this would make life for every audio-oriented distro.
This fits the new kernel development model very well, one of its stated
goals is to get the features that vendors and users need and that they
currently have to patch the kernel to get, into the mainstream kernel.
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...
Lee
7 Sep
7 Sep
8:50 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] realtime-lsm in the kernel
Hi Lee,
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. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Count my vote in.
BTW ...
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably, if
at all. It goes almost all through the init scripts to drop dead on the
beach, so to speak. It just freezes completely somewhere before the login
prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP boots
and runs fine. As I said before this was introduced on the Q5 patch, and
the same showstopper is present on latest R6. Only with Q3 I'm still
happy, altought only with softirq-preempt=0 AND hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS P4P800
mobo, 1GB DDR.
I would like some help in squaring out this mess. I'm feeling left behind
in this VP wagon... Even Ingo's site doesn't list Q3 anymore :(
Lee, could you care giving me some insight on how or who can I point my
thoughts about? ;)
Does anyone else?
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:04 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] realtime-lsm in the kernel
On Tue, 2004-09-07 at 18:31, Rui Nuno Capela wrote:
Hi Lee,
I posted the above report to LKML and cc'ed you and Ingo. None of the
LKML testers are reporting this problem, it sounds very similar to the
problems others have had with SMP/HT but those were thought to all be
solved.
This is a pretty good report, it should be easy to track this down since
we know exactly when it was introduced.
Has any version worked with softirq or hardirq preemption enabled? What
are the symptoms if you boot Q3 with either of the above enabled?
(Apologies to everyone if this turns into a long tedious kernel
debugging thread, but as you can see it's important for more people to
test these patches before they are ready for widespread use, and to see
what they might be in for ;-))
Lee
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. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Count my vote in.
BTW ...
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably, if
at all. It goes almost all through the init scripts to drop dead on the
beach, so to speak. It just freezes completely somewhere before the login
prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP boots
and runs fine. As I said before this was introduced on the Q5 patch, and
the same showstopper is present on latest R6. Only with Q3 I'm still
happy, altought only with softirq-preempt=0 AND hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS P4P800
mobo, 1GB DDR.
I would like some help in squaring out this mess. I'm feeling left behind
in this VP wagon... Even Ingo's site doesn't list Q3 anymore :(
Lee, could you care giving me some insight on how or who can I point my
thoughts about? ;)
Does anyone else? 
11:06 p.m.
New subject: [linux-audio-user] Re: [Jackit-devel] realtime-lsm in the kernel
On Tue, 2004-09-07 at 15:48, Lee Revell wrote:
(Apologies to everyone if this turns into a long
tedious kernel
debugging thread, but as you can see it's important for more people to
test these patches before they are ready for widespread use, and to see
what they might be in for ;-))
Lee
Don't be sorry. I Think it's good to watch the thread go by for a day or
a week. It helps when we get around to doing some of this ourselves.
BTW - people are reporting some really great results with some of Con
Kolivas' newest work. It will be interesting when the compaisons get
done...
- Mark
9:30 p.m.
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.
9:45 p.m.
On Wed, Sep 08, 2004 at 09:14:21AM EST, Malcolm Baldridge wrote:
I agree. I personally won't be shipping 2.6 kernels for my repository until
Slackware ships a 2.6 kernel out of the box, although I will make kernels with
these patches available for testing, so if a user breaks something, it is not
my problem.
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.
Hense the need for 2.6 kernels to be made available, but only for testing, so
problems can be worked out quicker and stability can be increased.
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. From a packager's point of view, having this patch
in the kernel does save some
work, but it is certainly no big a deal to build and
ship separately.
--
Luke Yelavich
http://www.audioslack.com
luke(a)audioslack.com
10:02 p.m.
On Tue, 2004-09-07 at 19:14, Malcolm Baldridge wrote:
Once people see how much better it works than 2.4+ll there will be no
stopping it.
The realtime-lsm module is ~200 lines of code. What is does to the
kernel can be summed up in one sentence.
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.
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. 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
11:19 p.m.
Once people see how much better it works than 2.4+ll
there will be no
stopping it.
Does it work better? I'm sure these things are changing daily, but the last
time I tested it with an oscilloscope connected to a parallel port control
line with an RTC-interrupt generated square wave toggle showed 2.4 having
less error when sampled over the course of an hour during routine system
usage testing (disk, graphics card, network I/O, etc).
From that test, having 2.6 simply MATCH 2.4's
performance would seem an
upgrade. Let alone, bettering it.
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.
The realtime-lsm module is ~200 lines of code. What
is does to the
kernel can be summed up in one sentence.
Ah, realtime-lsm - OK, I misread the subject (semantically, obviously). My
apologies.
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.
Yes, I did misread and assume the wrong thing about what you were referring
to. My apologies. If I could retract my post, I would. I'll just have to
put up verbal abuse as my punishment, I guess.
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.
You have examples of where an end-user/application-oriented popularity poll
swung a proposed patch into being adopted by the LK maintainers? I'm all eyes.
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.
Bleh. Fine, it's been 3 or 4 weeks since I've last look at source. If it's
changing that wildly, my original remarks have even more pertinence, not less.
I wasn't declaring a reality, I was simply pointing out the dangers of such
unbridled enthusiasm for a relatively untested kernel branch, as emitted in
your sentence:
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.
That is all. I wasn't picking a fight here. Bleeding edgers will always be
bleeding edgers, but the "fence-sitters" who are irrationally hoping for
"newer being a better solution" might be in a for a very rude shock.
Sheesh.
=MB=
--
A focus on Quality.
8 Sep
8 Sep
12:12 a.m.
On Tue, 2004-09-07 at 21:02, Malcolm Baldridge wrote:
Yes, it certainly does work better. I have boatloads of numbers to back
this up. In the past few weeks there have not been many new latency
fixes, mostly stability improvements and ports to other architectures.
For a regular UP 32-bit desktop x86 system it has been stable for
several weeks now.
OK, apology accepted. I made a similar mistake (read "debian stable"
where soneone wrote "unstable") on LKML the other day with similar
results... it happens.
The reason I posted this was that the 2.6 low latency patches are
starting to stabilize, and I didn't want to wait until they _were_ ready
for general use before trying to get realtime-lsm into the kernel. The
idea was to make the eventual, inevitable migration to 2.6 as smooth as
possible.
Once people
see how much better it works than 2.4+ll there will be no
stopping it.
Does it work better? I'm sure these things are changing daily, but the last
time I tested it with an oscilloscope connected to a parallel port control
line with an RTC-interrupt generated square wave toggle showed 2.4 having
less error when sampled over the course of an hour during routine system
usage testing (disk, graphics card, network I/O, etc).
From that test,
having 2.6 simply MATCH 2.4's performance would seem an
upgrade. Let alone,
bettering it.
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.
The realtime-lsm module is ~200 lines of code.
What is does to the
kernel can be summed up in one sentence.
Ah, realtime-lsm - OK, I misread the subject (semantically, obviously). My
apologies.
You have examples of where an
end-user/application-oriented popularity poll
swung a proposed patch into being adopted by the LK maintainers? I'm all eyes.
One of the goals of the new kernel development model worked out at OLS
was to get useful patches into the mainline kernel more quickly, because
vendors will just patch them in anyway.
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.
Bleh. Fine, it's been 3 or 4 weeks since I've last look at source. If it's
changing that wildly, my original remarks have even more pertinence, not less.
I wasn't declaring a reality, I was simply
pointing out the dangers of such
unbridled enthusiasm for a relatively untested kernel branch, as emitted in
your sentence:
Maybe you will be more enthusiastic as well once you test it. ;-)
Anyway my goal is to make it easier for people to try 2.6 when and if
they want to by eliminating the extra step of installing the
realtime-lsm module. I certainly did not mean to imply that it is ready
for production use. But we certainly do need more testers, as long as
they know what they are getting into. ;-)
Lee
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.
4:23 a.m.
On Tue, Sep 07, 2004 at 04:14:21PM -0700, Malcolm Baldridge wrote:
<snip>
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.
The kernel guys have a lieutenant looking after that. His name is Linus.
If the design is bad, it does not get into mainline.
--
Jack Bowling
mailto: jbinpg(a)shaw.ca
7 Sep
7 Sep
9:31 p.m.
On Tue September 7 2004 15:14, Lee Revell wrote:
<snip>
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...
</me comes out of lurking>
I would sign an electronic petition, send an e-mail or otherwise contribute my
voice to this drive. I've been using 2.6 kernels since the initial release
with very few hiccups on my system. I've only just started using audio
software under Linux, and I am super-excited about it. I can't stand the
thought of going back to 2.4.x kernels in terms of general system
responsiveness (my box is older -- PIII 450MHz -- and it's my desktop as well
as audio box. I guess you can see I'm just a hobbyist ;-).
I hope 2.6 becomes viable for the masses ASAP, and I'd love to see audio apps
ride the wave instead of playing catch-up. C'mon guys, bleeding edge is
FUN! ;-) j/k
Curtis
</me goes back to lurking...? TO BE CONTINUED ;-)>
8 Sep
8 Sep
1:43 a.m.
On Tuesday 07 September 2004 05:14 pm, Lee Revell wrote:
Hey,
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. Since this
means every single linux audio user will need the realtime-lsm module, I
think we should push to get it in the kernel, the sooner the better.
Why make every user go through the extra step of downloading and
installing it? It's only a few hundred lines of code, and while I don't
consider myself a kernel expert I can grok it easily. I can't imagine
there would be much resistance, especially considering how much easier
this would make life for every audio-oriented distro.
This fits the new kernel development model very well, one of its stated
goals is to get the features that vendors and users need and that they
currently have to patch the kernel to get, into the mainstream kernel.
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...
Me Too! :)
Lee
2:59 a.m.
New subject: [linux-audio-user] Re: realtime-lsm in the kernel
Lee Revell <rlrevell(a)joe-job.com> writes:
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...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-)
Adding it to the kernel sources would probably make maintenance
easier.
--
joq
3:08 a.m.
New subject: [linux-audio-user] Re: realtime-lsm in the kernel
On Wed, 2004-09-08 at 00:42, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
OK, great. I might as well do this before I get sick of LKML and
unsubscribe ;-).
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...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my
CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Can you send this to me? I will cc: you and Torben on anything I post.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-)
OK, since it will have his name on it too, I will see if he has any
objections before I post it.
Adding it to the kernel sources would probably make
maintenance
easier.
Yes, definitely. I see many more controversial, more complex, and less
useful features getting added to the kernel all the time, this seems
like a no brainer, because every audio user will need it. Once we get
this in the kernel it will be a one step process (apply Ingo's patches)
to get up and running on 2.6.
Lee
11 Sep
11 Sep
11:36 a.m.
New subject: [linux-audio-user] Re: realtime-lsm in the kernel
On Tue, Sep 07, 2004 at 11:42:35PM -0500, Jack O'Quin wrote:
Lee Revell <rlrevell(a)joe-job.com> writes:
of course i wont object :)
i just dont have much time for computers currently so i rarely read
mails...
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...
It's fine with me. I agree that it makes sense, but have not been
willing to hassle with the LKML, myself. Several others have
suggested it in the past, but no one was willing to push it through
the process.
If you do that, I'll help. I have a version in my CVS working tree
that will build as a kernel patch with the appropriate Kconfig and
Makefile updates. Please copy me on any messages you send to the
LKML, I'm not subscribed.
Torben was the original author, and I've been developing and
maintaining it since the end of 2003. I doubt he will object, but he
can speak for himself. :-) Adding it to the kernel sources would probably make
maintenance
easier.
yeah... #ifdefs in structs are pure evil :)
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
9 Sep
9 Sep
10:47 a.m.
On Tue, 07 Sep 2004 17:14:45 -0400
Lee Revell <rlrevell(a)joe-job.com> 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.
Since this means every single linux audio user will need the
realtime-lsm module, I think we should push to get it in the kernel,
the sooner the better.
Go for it. i would definetly like to save the extra step of compiling
the realtime lsm each time i upgrade my kernel.. And i think it might
prove useful even for non audio users.. Often security stuff likes to
mlock small portions of memory, too, etc..
flo
7322
days inactive
7326
days old
linux-audio-user@lists.linuxaudio.org
15 comments
11 participants
participants (11)
-
Curtis Sloan -
Florian Schmidt -
Jack Bowling -
Jack O'Quin -
John Check -
Lee Revell -
Luke Yelavich -
Malcolm Baldridge -
Mark Knecht -
Rui Nuno Capela -
torbenh＠gmx.de