Announcing the Audio Creation SIG / CCRMA merger effort

[Fernando Lopez-Lezcano]

On Wed, 2007-09-19 at 14:04 -0600, Richi Plana wrote:
> Hi, Fernando.
> 
> First of all, thanks for the comprehensive introduction.
> 
> On Wed, 2007-09-19 at 12:20 -0700, Fernando Lopez-Lezcano wrote:
> > Sorry, the source packages are common to all versions and architectures
> > currently supported. They all can be found here in the link posted by
> > Hans. Maybe I should write a script to cross link them but I'd rather be
> > doing other things....
> 
> Hopefully if things get transitioned to Fedora or one of the other
> third-party repos, it won't be necessary. There WILL be a discrepancy
> between your packages and the ones on Fedora as time goes by, though.

Hopefully not. As packages transition to Fedora I will drop them from
Planet CCRMA (that has already happened with some packages I originally
had in Planet CCRMA like, for example, rosegarden4 or lilypond). Not
immediately maybe, but surely when they are evr greater in Fedora or
when transitioning Planet CCRMA to a n+1 version of Fedora. 

[MUNCH]
> > Hope this all makes sense and answers your question...
> 
> It does answer things I've been wondering about, but I also wanted to
> know how many of the packages in PlanetCCRMA are still actively being
> developed or maintained. 

Most of them, I think. I don't keep a count. Some older stuff got
dropped but most is still around. Some packages don't see a big rate of
change but that does not mean they are not useful (they are actually
"stable" :-). 

> As well, are there any software packages in
> CCRMA that aren't packaged yet for PlanetCCRMA?

Pretty much everything we use is packaged. That's the point :-)
Remember, Planet CCRMA is a side effect of me trying to maintain a
usable sound environment at CCRMA. There are some exceptions, things
like matlab, but there are not many. 

> Also, some software might rely on a specific kernel (low-latency
> patches, etc.) Those packages which rely on that kernel might have to be
> tagged as requiring a low-latency kernel. 

No package _requires_ a low latency kernel. You can run everything on
top of the stock Fedora kernel if you want. The difference is that you
will not be able to reliably run Jack (the audio server most apps use)
at a low latency - by low I mean 5 or less milliseconds. That is needed
when you are using the computer as a performance instrument. And the
likelihood of an xrun happening (when the kernel takes too long in doing
something and the soundcard is starved of samples - and you get an
audible dropout) even at higher latencies goes up. And it all depends
also on what hardware you use and how you set it up. 

> Personally, I'd like to look
> into the package meta-info for this, but most likely it will mean having
> a package called kernel-ccrma (or -lowlatency or -rt or whatever). It
> will now be a part of the Fedora package namespace. To work with the
> rest of Fedora, we might need to transition those patches to the
> official Fedora kernel. 

That is happening but very slowly, Ingo has been slowly moving basic
infrastructure to the mainline kernel with the result that the realtime
preemption patch is smaller now (I think). But there is a LOT to be done
before the patch goes into the mainline kernel. And a LOT more before
the more aggresive (and useful) preemption options are enabled in a
stock Fedora build. I can hope.......

For now I don't see a low latency kernel happening in Fedora. Apps
first...

> This is specially important when the kmods get
> sucked into the kernel SRPM.

I don't quite follow you...

> Is there a way to tell which app packages need the -rt kernel?
> 
> Since you (Fernando) know the packages better than most, could you list
> the apps you think should be given higher priority for transitioning?

I can make a list, of course. I suggested already all the ladspa plugin
collections I host and that's what Hans already submitted, those have
immediate impact in all apps that use ladpsa plugins.

I'll post more suggestions tomorrow (time to go home)...

-- Fernando