I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases.
I saw the instructions for adding the real time patch for a tick less kernel and from what I can tell it wouldn't be hard to get that rolling as well.
I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users, and I'm still a bit of a noob so I could be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements.
I thought I read that ccrma uses a unique scheduler, but if we could get a 2ms latency time without it, the point may be moot.
On 02/14/2012 08:31 PM, Brian Monroe wrote:
I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases.
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
Currently 3.2.2-1.rt10.1 is in CCRMA testing (which is only one behind upstream which I believe Fernando has already started working on)
The patches are taken from here: http://www.kernel.org/pub/linux/kernel/projects/rt/
I saw the instructions for adding the real time patch for a tick less kernel and from what I can tell it wouldn't be hard to get that rolling as well.
I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users, and I'm still a bit of a noob so I could be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements.
That question might be better directed towards CCRMA.
I haven't got that far yet but I would imagine that any kernel shipped with a Fedora endorsed spin would have to be generated by the kernel team (ie, from the Fedora build system). Having said that, latency times achieved using the stock kernels w/threadirqs and our standard jack limits.conf are more than sufficient for most users.
I thought I read that ccrma uses a unique scheduler, but if we could get a 2ms latency time without it, the point may be moot.
Brendan
On Tue, Feb 14, 2012 at 12:21 PM, Brendan Jones brendan.jones.it@gmail.comwrote:
On 02/14/2012 08:31 PM, Brian Monroe wrote:
I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases.
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
yeah.
Currently 3.2.2-1.rt10.1 is in CCRMA testing (which is only one behind upstream which I believe Fernando has already started working on)
The patches are taken from here: http://www.kernel.org/pub/** linux/kernel/projects/rt/http://www.kernel.org/pub/linux/kernel/projects/rt/
I saw the instructions for adding the real time patch for a tick less kernel and from what I can tell it wouldn't be hard to get that rolling as well.
I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users, and I'm still a bit of a noob so I could be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements.
That question might be better directed towards CCRMA.
I haven't got that far yet but I would imagine that any kernel shipped with a Fedora endorsed spin would have to be generated by the kernel team (ie, from the Fedora build system). Having said that, latency times achieved using the stock kernels w/threadirqs and our standard jack limits.conf are more than sufficient for most users.
Is there a descent chance they would build a kernel for us? At least
the preemptive option if not the rt patch that Fernando is applying? The latency times I've been seeing for stock kernels haven't been great. They're fine for mixdowns or mastering but trying to record live or using it for performances I just don't see myself being able to use it without some serious work.
But maybe we're not trying to reach that user group?
I just think it'd be neat to give someone all the tools they need for audio creation, with little to no configuration (like a custom kernel)
On a side note, I think Macs have almost all of the market share for this. I also think that linux in general has been moving towards a more user friendly experience, and for audio I would imagine having a spin that isn't going to require that you install a new repository to get a new kernel, a lot of musicians are nerdy, but they're not that nerdy.
Now I'm just thinking out loud with this, and I don't know what the fedora culture is like but even if we could get it into standard repos would be a big deal. Even if that means we don't ship with the kernel installed, call it an "unstable-testing" kernel or something, that would be a big win for making things more practical for people using fedora for audio. I think people would try using it if there was ease of access.
I thought I read that ccrma uses a unique scheduler, but if we could get
a 2ms latency time without it, the point may be moot.
Brendan
______________________________**_________________ music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/musichttps://admin.fedoraproject.org/mailman/listinfo/music
Response below.
On 02/15/2012 12:49 AM, Brian Monroe wrote:
I just think it'd be neat to give someone all the tools they need for audio creation, with little to no configuration (like a custom kernel)
On a side note, I think Macs have ... not that nerdy.
Now I'm just thinking out loud with this, and I don't know what the fedora culture is like but even if we could get it into standard repos would be a big deal. Even if that means we don't ship with the kernel installed, call it an "unstable-testing" kernel or something, that would be a big win for making things more practical for people using fedora for audio. I think people would try using it if there was ease of access.
The last time we considered an alternative kernel, somebody found rules on the Fedora wiki saying that, if we want to be an official Fedora Spin, we must use the official Fedora kernel.
In my opinion, our best bet for kernel latency is our current path: build a Spin with the standard kernel, then make it easy to get the Planet CCRMA kernel installed.
<hijack>
I hoped the "Musicians' Guide" [0] would help with the "making easy" part. But after three releases, I haven't noticed a significant change in the Fedora audio community. Worse still, the list of things I want to revise keeps getting longer, while most of the document is still a first draft. It's not as fun or glamorous, but all copy-editing help or errors-pointing-out is appreciated.
</hijack>
Regards, Christopher.
[0] https://docs.fedoraproject.org/en-US/Fedora/16/html/Musicians_Guide/index.ht...
On 15/02/12 16:49, Brian Monroe wrote:
On Tue, Feb 14, 2012 at 12:21 PM, Brendan Jones brendan.jones.it@gmail.comwrote:
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
yeah.
I would be good to see real numbers associated with claims like the above; also how it is measured..
Also, indicate those various kernel patches and or options they use or have tested.
On 02/16/2012 04:33 AM, David Timms wrote:
On 15/02/12 16:49, Brian Monroe wrote:
On Tue, Feb 14, 2012 at 12:21 PM, Brendan Jones brendan.jones.it@gmail.comwrote:
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
yeah.
I would be good to see real numbers associated with claims like the above; also how it is measured..
Cyclictest is widely used for measuring latencies: https://rt.wiki.kernel.org/articles/c/y/c/Cyclictest.html
Also, indicate those various kernel patches and or options they use or have tested.
The rt patches for the latest kernels (3.2 at this point) are here: http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/
This is pretty much all I add to the rt patched kernels for Fedora (with the proper configuration options, of course, I'm attaching the extra options I'm currently using). To get the best performance in the Jack world you need to tune the irq kernel thread priorities, that is usually done using rtirq (http://www.rncbc.org/jack/#rtirq), and of course jackd should run with the proper rt priority as well.
-- Fernando
I didn't have time tonight to get tests on all the kernels under load, but here are the results, relatively load free.
I need to write a short python program to put the systems under duress. Hopefully I'll have time tommorrow to work on it and I can have the rest of the results in.
PS:I'm attaching some results from an RT kernel on a debian system below that they used while the box was recieving flood ping from an external source and repeated loops of hackbench 25 and ls -Ral /.
# cyclictest -a -t -n -p99 -i100 -d50 560.44 586.11 606.12 211/1160 3727 T: 0 (18617) P:99 I:100 C:1011846111 Min: 2 Act: 4 Avg: 5 Max: 39 T: 1 (18618) P:98 I:150 C: 708641019 Min: 2 Act: 5 Avg: 11 Max: 57
On Thu, Feb 16, 2012 at 10:37 AM, Fernando Lopez-Lezcano < nando@ccrma.stanford.edu> wrote:
On 02/16/2012 04:33 AM, David Timms wrote:
On 15/02/12 16:49, Brian Monroe wrote:
On Tue, Feb 14, 2012 at 12:21 PM, Brendan Jones brendan.jones.it@gmail.com**wrote:
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
yeah.
I would be good to see real numbers associated with claims like the above; also how it is measured..
Cyclictest is widely used for measuring latencies: https://rt.wiki.kernel.org/**articles/c/y/c/Cyclictest.htmlhttps://rt.wiki.kernel.org/articles/c/y/c/Cyclictest.html
Also, indicate those various kernel patches and or options they use or
have tested.
The rt patches for the latest kernels (3.2 at this point) are here: http://www.kernel.org/pub/**linux/kernel/projects/rt/3.2/http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/
This is pretty much all I add to the rt patched kernels for Fedora (with the proper configuration options, of course, I'm attaching the extra options I'm currently using). To get the best performance in the Jack world you need to tune the irq kernel thread priorities, that is usually done using rtirq (http://www.rncbc.org/jack/#**rtirqhttp://www.rncbc.org/jack/#rtirq), and of course jackd should run with the proper rt priority as well.
-- Fernando
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
On Tue, Feb 21, 2012 at 10:20 PM, Brian Monroe briancmonroe@gmail.comwrote:
I didn't have time tonight to get tests on all the kernels under load, but here are the results, relatively load free.
I need to write a short python program to put the systems under duress. Hopefully I'll have time tommorrow to work on it and I can have the rest of the results in.
PS:I'm attaching some results from an RT kernel on a debian system below that they used while the box was recieving flood ping from an external source and repeated loops of hackbench 25 and ls -Ral /.
# cyclictest -a -t -n -p99 -i100 -d50 560.44 586.11 606.12 211/1160 3727 T: 0 (18617) P:99 I:100 C:1011846111 Min: 2 Act: 4 Avg: 5 Max: 39 T: 1 (18618) P:98 I:150 C: 708641019 Min: 2 Act: 5 Avg: 11 Max: 57
On Thu, Feb 16, 2012 at 10:37 AM, Fernando Lopez-Lezcano < nando@ccrma.stanford.edu> wrote:
On 02/16/2012 04:33 AM, David Timms wrote:
On 15/02/12 16:49, Brian Monroe wrote:
On Tue, Feb 14, 2012 at 12:21 PM, Brendan Jones brendan.jones.it@gmail.com**wrote:
Latency times are really relative things based on many factors. Have you been getting better latency times than ta
yeah.
I would be good to see real numbers associated with claims like the above; also how it is measured..
Cyclictest is widely used for measuring latencies: https://rt.wiki.kernel.org/**articles/c/y/c/Cyclictest.htmlhttps://rt.wiki.kernel.org/articles/c/y/c/Cyclictest.html
Also, indicate those various kernel patches and or options they use or
have tested.
The rt patches for the latest kernels (3.2 at this point) are here: http://www.kernel.org/pub/**linux/kernel/projects/rt/3.2/http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/
This is pretty much all I add to the rt patched kernels for Fedora (with the proper configuration options, of course, I'm attaching the extra options I'm currently using). To get the best performance in the Jack world you need to tune the irq kernel thread priorities, that is usually done using rtirq (http://www.rncbc.org/jack/#**rtirqhttp://www.rncbc.org/jack/#rtirq), and of course jackd should run with the proper rt priority as well.
-- Fernando
music mailing list music@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/music
On 02/21/2012 10:28 PM, Brian Monroe wrote:
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
Hi Brain, and thanks for testing and sharing the results. Which CCRMA rt kernel were you testing? It'd be nice if you did an uname -a before each test... -- Fernando
On 02/21/2012 10:47 PM, Fernando Lopez-Lezcano wrote:
On 02/21/2012 10:28 PM, Brian Monroe wrote:
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
Hi Brain,
Argh, Brian, of course... sorry...
and thanks for testing and sharing the results. Which CCRMA rt kernel were you testing? It'd be nice if you did an uname -a before each test... -- Fernando
I'll be sure to include that on the next batch. I used the kernel you after installing the CCRMA repo when you use yum install kernel-rt, which happens to be 3.0.17-1.rt33.1.fc16.ccrma.x86_64.rt. I'll go back and include the other info to the old results when I do the load testing tonight or tomorrow. On Feb 21, 2012 11:01 PM, "Fernando Lopez-Lezcano" nando@ccrma.stanford.edu wrote:
On 02/21/2012 10:47 PM, Fernando Lopez-Lezcano wrote:
On 02/21/2012 10:28 PM, Brian Monroe wrote:
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
Hi Brain,
Argh, Brian, of course... sorry...
and thanks for testing and sharing the results.
Which CCRMA rt kernel were you testing? It'd be nice if you did an uname -a before each test... -- Fernando
Ok, I redid all the tests, while the system was only running my DE and the test, and then again when I put it under duress by running a script that looped "du -h /" and "ls -Ral /usr/" over and over. I ran the script twice to get my proc up a bit to emulate running some intese delays and reverbs or other effects.
Ironically the kernels typically did better when the scripts were running. Personally I think there's a clear advantage with CCRMA's kernel or even just a preempt kernel in the max lat areas. Those max numbers jumped up close to where they were near the beggining of the test if anyone was wondering.
Here's the file with both sets of tests and the uname -a info as requested by Fernando.
-Brian
On Wed, Feb 22, 2012 at 6:54 AM, Brian Monroe briancmonroe@gmail.comwrote:
I'll be sure to include that on the next batch. I used the kernel you after installing the CCRMA repo when you use yum install kernel-rt, which happens to be 3.0.17-1.rt33.1.fc16.ccrma.x86_64.rt. I'll go back and include the other info to the old results when I do the load testing tonight or tomorrow. On Feb 21, 2012 11:01 PM, "Fernando Lopez-Lezcano" < nando@ccrma.stanford.edu> wrote:
On 02/21/2012 10:47 PM, Fernando Lopez-Lezcano wrote:
On 02/21/2012 10:28 PM, Brian Monroe wrote:
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
Hi Brain,
Argh, Brian, of course... sorry...
and thanks for testing and sharing the results.
Which CCRMA rt kernel were you testing? It'd be nice if you did an uname -a before each test... -- Fernando
So I had a beer with hansomepirate(jdulaney), who is, or was on the kernel sig, last night and we got to talking about a RT kernel.
Last time we talked to the kernel folks about an rt kernel, they weren't impressed with the "need" for Fedora, but that was before the Spin was officially out.
Now might be a good time to raise this issue again? I dug through my archives and found this thread. Now that we have an actual spin that's out, we can actually redo some of the testing to have more realistic tests. (multitrack with effects)
I feel like right now, it's one of the few benefits that the ubuntu studio folks have (or at least claim to have) over us. The other is some semi-proprietary software that on... you know what, never mind it's getting off topic.
Anyways, does the list think this is worth pursuing?
On Wed Feb 22 2012 at 9:10:29 PM Brian Monroe briancmonroe@gmail.com wrote:
Ok, I redid all the tests, while the system was only running my DE and the test, and then again when I put it under duress by running a script that looped "du -h /" and "ls -Ral /usr/" over and over. I ran the script twice to get my proc up a bit to emulate running some intese delays and reverbs or other effects.
Ironically the kernels typically did better when the scripts were running. Personally I think there's a clear advantage with CCRMA's kernel or even just a preempt kernel in the max lat areas. Those max numbers jumped up close to where they were near the beggining of the test if anyone was wondering.
Here's the file with both sets of tests and the uname -a info as requested by Fernando.
-Brian
On Wed, Feb 22, 2012 at 6:54 AM, Brian Monroe briancmonroe@gmail.com wrote:
I'll be sure to include that on the next batch. I used the kernel you after installing the CCRMA repo when you use yum install kernel-rt, which happens to be 3.0.17-1.rt33.1.fc16.ccrma.x86_64.rt. I'll go back and include the other info to the old results when I do the load testing tonight or tomorrow. On Feb 21, 2012 11:01 PM, "Fernando Lopez-Lezcano" < nando@ccrma.stanford.edu> wrote:
On 02/21/2012 10:47 PM, Fernando Lopez-Lezcano wrote:
On 02/21/2012 10:28 PM, Brian Monroe wrote:
Bah, I forgot to save before I uploaded, here's the text file with the CCRMA results.
Hi Brain,
Argh, Brian, of course... sorry...
and thanks for testing and sharing the results.
Which CCRMA rt kernel were you testing? It'd be nice if you did an uname -a before each test... -- Fernando
On 02/14/2012 11:31 AM, Brian Monroe wrote:
I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases.
The latest I have, current in testing is 3.2.2 + rt11 (for Fedora 15 and 16). I am currently trying to build 3.2.6 + rt12.
The current rt not in testing is a 3.0.x based release (fc15/16). I have not seen a big interest on being up to date - I just try to keep up with the latest rt patch set. If there is more interest I could try to keep up (but keeping up with _what_?, for a bit I was testing a 3.2 based rt patched kernel and that was still not available for fc16 as an official release).
I saw the instructions for adding the real time patch for a tick less kernel and from what I can tell it wouldn't be hard to get that rolling as well.
I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users,
"compared to other Linux users"? I don't follow.
and I'm still a bit of a noob so I could be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements.
I thought I read that ccrma uses a unique scheduler, but if we could get a 2ms latency time without it, the point may be moot.
Nope, no unique scheduler or other stuff. Where did you read that? (links please?)
The Planet CCRMA rt patched kernels are based on recent Fedora source packages (usually from Koji) that are the closest I can find to the kernel releases for which rt patches are available. To that source package I add the rt patch, drop Fedora patches that are already included or conflict, and built that. I use pretty much the stock Fedora kernel configuration files except for whatever tweaks are necessary to enable the rt patch for full preemption. That's about it.
As work in the rt patches has progressed the stock Fedora kernel (which is basically upstream plus a few patches that have not been merge yet) has become more and more usable for "normal" music work. For low latency work (in a word, using your computer as a musical instrument), an rt patched kernel still has an edge. Whether that really makes a difference depends on your usage, your tolerance to occasional xruns and even the exact hardware you are running on.
-- Fernando
On Tue, Feb 14, 2012 at 12:21 PM, Fernando Lopez-Lezcano < nando@ccrma.stanford.edu> wrote:
On 02/14/2012 11:31 AM, Brian Monroe wrote:
I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases.
The latest I have, current in testing is 3.2.2 + rt11 (for Fedora 15 and 16). I am currently trying to build 3.2.6 + rt12.
Ah, that may have been an error on my part, I thought last I checked, which admittedly was a week and a half ago there was only a F15 kernel on the CCRMA website.
The current rt not in testing is a 3.0.x based release (fc15/16). I have not seen a big interest on being up to date - I just try to keep up with the latest rt patch set. If there is more interest I could try to keep up (but keeping up with _what_?, for a bit I was testing a 3.2 based rt patched kernel and that was still not available for fc16 as an official release).
I saw the instructions for adding the real time patch for a tick less
kernel and from what I can tell it wouldn't be hard to get that rolling as well.
I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users,
"compared to other Linux users"? I don't follow.
Namely the Ubuntu Studio folks. Most users in #opensourcemusicians seem to use Ubuntu. Why? I don't know.
and I'm still a bit of a noob so I could
be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements.
I thought I read that ccrma uses a unique scheduler, but if we could get a 2ms latency time without it, the point may be moot.
Nope, no unique scheduler or other stuff. Where did you read that? (links please?)
To be honest I'm not sure where I read this, but I do remember having conversations about it in one of the channels. Part of the reason I wanted to email the list was to hear what's what from the source, so thanks for clearing that up for me.
The Planet CCRMA rt patched kernels are based on recent Fedora source packages (usually from Koji) that are the closest I can find to the kernel releases for which rt patches are available. To that source package I add the rt patch, drop Fedora patches that are already included or conflict, and built that. I use pretty much the stock Fedora kernel configuration files except for whatever tweaks are necessary to enable the rt patch for full preemption. That's about it.
Is there any help needed for testing/ect? I'm just trying to figure out what I can do to start contributing.
As work in the rt patches has progressed the stock Fedora kernel (which is basically upstream plus a few patches that have not been merge yet) has become more and more usable for "normal" music work. For low latency work (in a word, using your computer as a musical instrument), an rt patched kernel still has an edge. Whether that really makes a difference depends on your usage, your tolerance to occasional xruns and even the exact hardware you are running on.
-- Fernando
On 02/14/2012 08:55 PM, Brian Monroe wrote:
On Tue, Feb 14, 2012 at 12:21 PM, Fernando Lopez-Lezcano <nando@ccrma.stanford.edu mailto:nando@ccrma.stanford.edu> wrote:
On 02/14/2012 11:31 AM, Brian Monroe wrote: I've been spending a lot of time on the #opensourcemusicians channel talking to Ubuntu Studio users about their kernel and latency times they're getting. Seems like most of them are using g a stock kernel with the preemptive option enabled and they are getting great latency results (2ms)while utilizing the @audio group on their user. I ended up compiling my own low latency kernel and I haven't had any issues with it yet. If this is what we are missing for the spin I'd be happy to maintain packaging for the kernel. I know ccrma has been behind a few kernel releases. The latest I have, current in testing is 3.2.2 + rt11 (for Fedora 15 and 16). I am currently trying to build 3.2.6 + rt12.Ah, that may have been an error on my part, I thought last I checked, which admittedly was a week and a half ago there was only a F15 kernel on the CCRMA website.
The web site needs updating (and I just released 3.2.6 rt12 for fc16 testing)... Pretty much everything that is available for fc15 is available for fc16 (I have been using the mailing lists to announce stuff and never have time to update the web site). Install planetccrma-repo and that should get you going.
The current rt not in testing is a 3.0.x based release (fc15/16). I have not seen a big interest on being up to date - I just try to keep up with the latest rt patch set. If there is more interest I could try to keep up (but keeping up with _what_?, for a bit I was testing a 3.2 based rt patched kernel and that was still not available for fc16 as an official release). I saw the instructions for adding the real time patch for a tick less kernel and from what I can tell it wouldn't be hard to get that rolling as well. I'm not entirely sure what ccrma does differently with their kernels compared to other Linux users, "compared to other Linux users"? I don't follow.Namely the Ubuntu Studio folks. Most users in #opensourcemusicians seem to use Ubuntu. Why? I don't know.
Probably part of the reason is that not being a US based distribution it does not care about some stuff that makes Fedora harder to use (the codec patent minefield). Fedora also has a reputation of being bleeding edge, more so than Ubuntu. As a technology testing ground it has in the past made decisions that advanced the state of the art (although some users question whether what happened was an "advance") and broken important audio stuff as a side effect, sometimes for a long time. That chases users away. I can atest to that.
and I'm still a bit of a noob so I could be off base with this, but I would reason that we should be able to just utilize the same settings to archive similar performance enhancements. I thought I read that ccrma uses a unique scheduler, but if we could get a 2ms latency time without it, the point may be moot. Nope, no unique scheduler or other stuff. Where did you read that? (links please?)To be honest I'm not sure where I read this, but I do remember having conversations about it in one of the channels. Part of the reason I wanted to email the list was to hear what's what from the source, so thanks for clearing that up for me.
The Planet CCRMA rt patched kernels are based on recent Fedora source packages (usually from Koji) that are the closest I can find to the kernel releases for which rt patches are available. To that source package I add the rt patch, drop Fedora patches that are already included or conflict, and built that. I use pretty much the stock Fedora kernel configuration files except for whatever tweaks are necessary to enable the rt patch for full preemption. That's about it.Is there any help needed for testing/ect? I'm just trying to figure out what I can do to start contributing.
If you are a Fedora user and you are interested in low latency kernels you can of course try the Planet CCRMA kernel-rt and kernel-rtPAE packages I maintain (plus rtirq and other goodies, install "planetccrma-core" or "planetccrma-core-PAE"). BTW, it is only recently that 3.0 and 3.2 kernels have evolved to a state where they behave as well or better than good'old 2.6.33.x, at leaste IMO.
As for an audio oriented spin that is _really_ good, the only way that can happen officially in Fedora (AFAIK) is for the upstream kernel to become good enough for that without the rt patches. It is probably getting there in terms of source code, but for the Fedora kernel to become better than average it would need to be rebuilt with more appropriate configuration options, namely threaded irq's.
-- Fernando
-
Brendan Jones -
Brian Monroe -
Christopher Antila -
Development discussions related to Fedora -
Fernando Lopez-Lezcano