I also thought that it was an interesting talk. I'd be interested in
hearing the status of this project as well.
On Wed, 2006-05-31 at 12:00 -0400, fedora-music-list-request(a)redhat.com
> Send Fedora-music-list 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 Fedora-music-list digest..."
> Today's Topics:
> 1. jack and sound servers (Anthony Green)
> Message: 1
> Date: Tue, 30 May 2006 13:05:50 -0700
> From: Anthony Green <green(a)redhat.com>
> Subject: [Fedora-music-list] jack and sound servers
> To: fedora-music-list(a)redhat.com
> Message-ID: <1149019550.6060.99.camel(a)localhost.localdomain>
> Content-Type: text/plain
> Good news... jack-audio-connection-kit is in extras-development.
> Also, about 6 months too late, I watched some of the videos from the
> Boston FUDCon a few months ago...
> The videos include a talk about sound on Linux, and it touches on jack,
> LADSPA, etc. The presenter, Chris Montgomery, talks about a plan to
> write a new sound server for Fedora that will satisfy both real- and
> non-real-time audio applications. I don't know if anything has come of
> that yet, but it would be interesting to hear an update if anybody here
> has one.
> Fedora-music-list mailing list
> End of Fedora-music-list Digest, Vol 2, Issue 14
Good news... jack-audio-connection-kit is in extras-development.
Also, about 6 months too late, I watched some of the videos from the
Boston FUDCon a few months ago...
The videos include a talk about sound on Linux, and it touches on jack,
LADSPA, etc. The presenter, Chris Montgomery, talks about a plan to
write a new sound server for Fedora that will satisfy both real- and
non-real-time audio applications. I don't know if anything has come of
that yet, but it would be interesting to hear an update if anybody here
I am seriously looking at upgrading to FC5 primarily because it is
reported to be an openGL 2.0 compliant system and Gem (a visualization
labrary for PD) is now requiring openGL 2.0 for full Gem functionality.
But I am a long time CCRMA fan and the packages and kernel offered by
CCRMA for FC4 really make my musical life easier. And so I ask: is
there an FC5 CCRMA kernel and packages repository yet?
I would really love to not have to go back to building my own kernels
using Ingo M.'s patches and then having to build all my sound tools
myself using rpmbuild.
Thank you all,
Can the list maintainer please remove the [fedora-music-list] junk
from the mailing list subject line? It's 2006 now, and I believe
the majority of people subscribing to mailing lists have long since
realized how to filter mail using X-BeenThere, or whatever other
There is no good reason to plaster the list name in the subject of
every single message. All other Fedora and Red Hat lists consistently
do not have this junk in the subject line. What's more is that
if there are people who /do/ prefer to have that junk there, they
can add it back to their own messages locally using procmail,
and sed or formail.
Thanks in advance.
Mike A. Harris * Open Source Advocate * http://mharris.ca
I am a bit of lurker on this list - I have a general interest in music
(I am a biologist but work as an IT professional). I have been using
Fedora and RH for a long time so this a probably a good group to ask the
question: Is there FC5 compatible software around for teaching yourself
to read music? I guess I need to at least have an epiano keyboard with
Pricom Pty Limited (ACN 003 252 275 ABN 91 003 252 275)
GPO Box 3411
Sydney NSW 2001
Hello everyone. I needed Rosegarden for a class, and since CCRMA isn't
built for FC5 and x86_64, I attempted to build the CCRMA source package
myself. And discovered I needed the latest Rosegarden to build with GCC
4.1, which changed to scons, which has some icky bugs, one of which I
fixed with a patch from Fernando I dug up on a mailing list, then I
discovered a bug in mock, etc... And since I went through all the effort
I submitted it to Extras.
I did a lot of googling trying to find out if there was any activity as
far as merging CCRMA into Extras and found nothing recent. (It appears
this list was created shortly *after* I looked...) I had intended to
email Fernando directly but never got around to it. Heh.
I could use some advice on what to do about the timing problem... (Been
meaning to take that up on Rosegarden's mailing list...)
I took it upon myself to slap up a quickie SIG page on the wiki:
I chose the name Media Production. Media allows us to include video as
well (Cinelerra). Production emphasizes that distribution and
consumption (patented codecs, media players, PVRs, streaming servers...)
do not fall directly under the SIG's focus.
So does "Media Production SIG" sound good to everyone?
I've been doing my best to hurry up the review of jack. Its finals
week(s) so I'm busy, sleep deprived, and stressed out, however one of my
finals *is* for Digital Synth & Composition, so I can justify spending
at least some time on audio stuff. :)
I would suggest a nice simple easy to refer to name that Jolene Sixpack
can remember and, more importantly, use. Put away the geek speak
folks. If nothing else do what the Beatles did and call it an Apple.
That may P.O. a few folks, but you can't copyright fruit. Perhaps
L-Apple or lapple for Linux Apple. or Fapple for Fedora Apple or
FedApple whoopsie - too scary. Keep up the great work pals and I might
add that exyum went bananas (hey another good name) when I tried to load
just about anything from CCRMA. Of course, I am an early adopter and am
running core 5.
Ed Black, Ph.D.
Sorry I didn't mean to reply to Thorsten off-list.
On 5/10/06, Tim Mayberry <mojofunk(a)gmail.com> wrote:
> On 5/9/06, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> > Am Dienstag, den 09.05.2006, 16:31 +1000 schrieb Tim Mayberry:
> > The old plan was to move alsa-firmware to livna. The current plan is to
> > solve the problems with alsa-firmware and ship what can be shipped.
> > Someone (Legal, FESCo) simply has to say what files from alsa-firmware
> > are okay for Extras, and what not. The last I heard was this:
> > ----
> > > I maintained some alsa-firmware in the old fedora.us days. During the
> > > transition to Fedora Extras the package got "lost" -- it was unclear if
> > > the files in it were okay for the official Fedora Extras. See
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143249#c3
> > >
> > > We dropped it then and forwarded the issue to legal. It got lost or was
> > > forgotten, I can't remember. But I'd like to get this solved now that
> > > someone asked for a Extras package of alsa-firmware in bugzilla.
> > >
> > > So, where were the problems? Here is the main one:
> > >
> > > > $ file ./mixartloader/miXart8.elf
> > > > ./mixartloader/miXart8.elf: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
> > That is a pretty big problem.
> > Some of this is probably ok for FE, but only those bits which are not
> > libraries or binaries.
> As I remember this issue was debated a fair bit on the debian lists a
> while back, I didn't follow it too closely but I think they ended up
> splitting the alsa-tools source package into alsa-tools and
> alsa-firmware-loaders, with alsa-tools corresponding to roughly what
> is in the FE alsa-tools package currently and alsa-firmware-loaders
> being what is not. You then have to download the alsa-firmware
> package from the ALSA website and configure it etc, which is not at
> all ideal and I'm not suggesting it but it would still be better than
> it is currently.
> I haven't been able to find a clear explanation of the Fedora Extras
> policy on packaging firmware but I haven't looked that hard
> yet(perhaps you could offer some pointers), I'd be surprised if any of
> the files in alsa-firmware would be able to be ok for FE.
> > We should split alsa-firmware -- the "mostly free" parts should land in
> > Extras, the others in Livna. Are you interested in doing this. I simply
> > have no time for it ATM, never really was interested this alsa-firmware
> > stuff and I don't even have hardware to test. Are you interested in
> > driving this forward? You can of course count on my help.
> The problem then becomes defining what can and cannot be packaged and
> where. I'm quite willing to help driving this forward but I am not
> qualified to work through any legal issues. I'd rather solve this
> problem more quickly on a technical level if possible, even if it is
> only somewhat temporary until a better arrangement can be worked out.
> It seems like you are suggesting splitting the upstream alsa-tools and
> alsa-firmware into 4 or 5 packages that would then reside in 2
> separate repositories...
> FE repo:
> alsa-tools.srpm -> alsa-tools.rpm, alsa-firmware-loaders-for-free-firmware.rpm
> alsa-firmware.srpm -> alsa-firmware-free.rpm (If there is such a thing)
> Livna/other repo:
> alsa-tools.srpm -> alsa-firmware-loaders-for-non-free-firmware.rpm
> alsa-firmware.srpm -> alsa-firmware-non-free.rpm
> Apart from all the obvious issues with something like that there is
> still then the problem that some of the tools from the alsa-tools
> package are still indirectly dependent on non-free firmware unless you
> further split the packages.
> I think I would prefer to modify the alsa-tools package so that it
> builds everything from the upstream source including firmware loaders
> as there are no legal issues with that as far as I know(only with the
> firmware itself). Then for an alsa-firmware rpm to reside in an
> external repository and require alsa-tools from FE.
> Or alternatively, do what debian has done and split alsa-tools into
> alsa-tools and alsa-firmware-loaders and have an externally hosted
> alsa-firmware package dependent on alsa-firmware-loaders.
> I'm a bit rushed today so I hope that all came out alright. I look
> forward to help resolving this issue.
When I was a grad student at Carnegie Tech (now Carnegie Mellon) I used
to dream of a cadre of programmers whose sole aim was to make the world
a better place. Now that I am sixty, my coding days are over, but with
every day Linux make my dream come true. We are almost there, keep up
the great work and a heartfelt congratulations.
Ed Black, Ph.D.