Hello Fedora musicians, I've been lurking this list for a little bit and this is my first time chiming in on something.
I think it is important to pursue an official realtime kernel for Fedora. I think a distribution focused on audio without a realtime kernel would have a serious bug, that IMO, would be worth delaying publication for.
>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
>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
>Anyways, does the list think this is worth pursuing?
>>On Wed Feb 22 2012 at 9:10:29 PM Brian Monroe <briancmonroe at gmail.com[https://admin.fedoraproject.org/mailman/listinfo/music]>
>> 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
>> Here's the file with both sets of tests and the uname -a info as requested
>> by Fernando.
>>> On Wed, Feb 22, 2012 at 6:54 AM, Brian Monroe <briancmonroe at gmail.com[https://admin.fedoraproject.org/mailman/listinfo/music]
>>> 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.
Hello Fedora musicians, I've been lurking this list for a little bit and
> this is my first time chiming in on something.
> I think it is important to pursue an official realtime kernel for Fedora.
> I think a distribution focused on audio without a realtime kernel would
> have a serious bug, that IMO, would be worth delaying publication for.
Real Time Kernels are available from PlanetCCRMA:
There are concerns about the implementation of Real Time Kernel as
expressed in the Musician's Guide:
I am not a systems programmer so I can't speak to these concerns. Some of
the names of the real time kernel developers listed on the PlanetCCRMA
kernel-rt page are Red Hat employees.
I would like to see Fedora be the premier linux distribution for music.
But until we can overcome the concerns listed in the Musician's Guide we
will probably not have a real time kernel in the Fedora repositories.
Maybe a Fedora "Re-Mix", or Fedora.Next and Workstation with the works with
Fedora software library may break the ice.
I had some spare time to do some updates on rawhide and F-21. So I
updated jack to 1.9.10. The qjackctl and qsynth packages were a little
outdated. I updated them as well. Feel free to test and leave karma.
As some of you have probably noticed, the spin won't be included this
release on the spins page. This is because we didn't do the testing in
time. The nightly composes are still creating the spin (and will always
be up to date with the latest packages rather than a snapshot at release
time). We also have the new "Audio Production" yum group which allows
you to install the audio packages on a system with your desktop
environment of choice.
I have updated the pages here  and here :
I wanted to reach out to the list and ask a quick question: I'm looking to
have RedHat join NAMM (National Association of Music Makers), I'm also
involved with Fedora Ambassadors and I wanted to know if anyone here is
interested in going to either of the NAMM shows to promote
Fedora/OpenSource there. I live pretty close to Anaheim so the costs are
almost non-existent for me and I'm even willing to pitch in to help cover
the cost of getting in. There's a lot of cool stuff at NAMM, including all
of this years new gear, but we need some people (musicians/musos) that are
interested in reaching out to a new group that knows little to nothing
There are two shows: One is January 22-25, in Anaheim, CA, and the other is
July 9-11, in Nashville TN. (Potentially there's a third and fourth show in
Russia in September, but I don't have exact dates, additional fees, or
locations for those, and there will probably be an addition cost but still
let me know if you're interested in attending those or are conencted with
APAC or EMEA as I'm not sure what Russia would fall under).
We have four tickets, but I'm not sure if RedHat will be sending anyone, or
if I already have a second person to help me. At this point I'm not sure if
there's going to be any money provided to help out with travel costs, but
it's a possibility so right now I'm looking for people that are able and
willing to attend with the intention of discussing Fedora over gawking at
all the shiny and free stuff (there will still be plenty of time for that).
Can someone enlighten me why we forked these packages with the naming
scheme this way?
I know that the licensing changed from the version 2 and version 3 releases
and caused us to package them separately, but it seems to me like it's
backwards. Is there a fedora policy that would prohibit us from packaging
ardour3 under the package name ardour and ardour ver 2 under ardour2.
I can see this as being a potentially sore spot for new users to try to
install Ardour with "yum install ardour" and being disappointed and or
confused with why Fedora is a whole version behind. Or bewildered when they
start using the program and it doesn't look right and the menus are all
wrong according to the website.
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
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.
i've installed gladish and the ladish tools but something seems to be
broken. running ladi-control-center from the command line claimed for xdg
library. i've fixed the issue installing pyxdg, xdg-user-dirs, xdg-utils.
actually, i'm not sure about xdg-*, since now the system does not allow me
to remove them since it seems they are used from other applications.
i had to fix also the JACK conf tool in gladish-->Tools-->Settings. it was
ladiconf (file not found), fixed using ladi-control-center
same for ladi tray: i had to install python-appindicator (and related
dependencies), libappindicator (and related dependencies),
libappindicato-gtk3 (and related dependencies) to get it working
now it seems to be ok
Le mer. 5 nov. 2014 13:01, null <music-request(a)lists.fedoraproject.org> a
> Send music mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of music digest..."
> Today's Topics:
> 1. Broken dependencies for ladish tools?
> (The name of my band is 1984)
> Message: 1
> Date: Tue, 4 Nov 2014 22:11:03 +0100
> From: The name of my band is 1984 <thenameofmybandis1984(a)gmail.com>
> To: music(a)lists.fedoraproject.org
> Subject: [Fedora-music-list] Broken dependencies for ladish tools?
> Content-Type: text/plain; charset="utf-8"
> i've installed gladish and the ladish tools but something seems to be
> broken. running ladi-control-center from the command line claimed for xdg
> library. i've fixed the issue installing pyxdg, xdg-user-dirs, xdg-utils.
> actually, i'm not sure about xdg-*, since now the system does not allow me
> to remove them since it seems they are used from other applications.
> i had to fix also the JACK conf tool in gladish-->Tools-->Settings. it was
> ladiconf (file not found), fixed using ladi-control-center
> same for ladi tray: i had to install python-appindicator (and related
> dependencies), libappindicator (and related dependencies),
> libappindicato-gtk3 (and related dependencies) to get it working
> now it seems to be ok
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.fedoraproject.org/pipermail/music/
> music mailing list
> End of music Digest, Vol 86, Issue 3