ardour 2.4 was out

[ZC Miao]

[quote]
Ardour 2.4 released
Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
Well, its over a month later than expected, but Ardour 2.4 is finally
here. A respectable list of new features, many small improvements and an
important set of bug fixes make up the news for this one. Read more
below ...
[/quote]

So, when will we get it in F8?

Thanks, regards,

--
ZC Miao (hellwolf.misty(a)gmail.com)
Blog http://hellwolf.cublog.cn

gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F

[Hans de Goede]

ZC Miao wrote:
>  [quote]
>  Ardour 2.4 released
>  Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>  Well, its over a month later than expected, but Ardour 2.4 is finally
>  here. A respectable list of new features, many small improvements and an
>  important set of bug fixes make up the news for this one. Read more
>  below ...
>  [/quote]
>  
>  So, when will we get it in F8?
>   
In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering that 
this not purely a bug fix release I'm not sure if we want to release this as an 
update to F-8. What do others on this list think?

You could grab the srpm from rawhide and build it for F-8, and provide us with 
some feedback on it, that might help.

Regards,

Hans

[Peter Hartmann]

Building from source it is pretty easy on fedora....

scons PREFIX=/usr

as root:

scons install

to uninstall:

scons uninstall PREFIX=/usr




Peter

On Sun, Apr 6, 2008 at 4:10 PM, ZC Miao <hellwolf.misty(a)gmail.com&gt; wrote:
>  [quote]
>   Ardour 2.4 released
>   Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>   Well, its over a month later than expected, but Ardour 2.4 is finally
>   here. A respectable list of new features, many small improvements and an
>   important set of bug fixes make up the news for this one. Read more
>   below ...
>   [/quote]
>
>   So, when will we get it in F8?
>
>   Thanks, regards,
>
>   --
>   ZC Miao (hellwolf.misty(a)gmail.com)
>   Blog http://hellwolf.cublog.cn
>
>   gpg --keyserver pgp.mit.edu --recv-key 0x6B174C6F
>
>
>   _______________________________________________
>   Fedora-music-list mailing list
>   Fedora-music-list(a)redhat.com
>   http://www.redhat.com/mailman/listinfo/fedora-music-list
>

[Fernando Lopez-Lezcano]

On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
>  ZC Miao wrote:
>  > [quote]
>  > Ardour 2.4 released
>  > Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>  > Well, its over a month later than expected, but Ardour 2.4 is finally
>  > here. A respectable list of new features, many small improvements and an
>  > important set of bug fixes make up the news for this one. Read more
>  > below ...
>  > [/quote]
>  > 
>  > So, when will we get it in F8?
>  > 
>  
>  In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering that 
>  this not purely a bug fix release I'm not sure if we want to release this as an 
>  update to F-8. What do others on this list think? 
I would release it on Fedora 8. It has bug fixes and I think other users
would probably appreciate having the latest. 

>  You could grab the srpm from rawhide and build it for F-8, and
> provide us with 
>  some feedback on it, that might help. 
I'll probably try a release in the Planet CCRMA testing repos...
-- Fernando

[Anthony Green]

Nicholas Manojlovic wrote:
>  I think I preferred it when Ardour was in the CCRMA repo. Not only
> was 
>  it quicker, I trust its been built with music in mind.
>  
What do you mean by "built with music in mind"?  What else would we 
build it for?

AG

[Nicholas Manojlovic]

I think I preferred it when Ardour was in the CCRMA repo. Not only was it
quicker, I trust its been built with music in mind.



On Wed, Apr 9, 2008 at 4:24 AM, Fernando Lopez-Lezcano <
nando(a)ccrma.stanford.edu&gt; wrote:

>  On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
>  > ZC Miao wrote:
>  > > [quote]
>  > > Ardour 2.4 released
>  > > Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>  > > Well, its over a month later than expected, but Ardour 2.4 is finally
>  > > here. A respectable list of new features, many small improvements and
>  an
>  > > important set of bug fixes make up the news for this one. Read more
>  > > below ...
>  > > [/quote]
>  > >
>  > > So, when will we get it in F8?
>  > >
>  >
>  > In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering
>  that
>  > this not purely a bug fix release I'm not sure if we want to release
>  this as an
>  > update to F-8. What do others on this list think?
>
>  I would release it on Fedora 8. It has bug fixes and I think other users
>  would probably appreciate having the latest.
>
>  > You could grab the srpm from rawhide and build it for F-8, and provide
>  us with
>  > some feedback on it, that might help.
>
>  I'll probably try a release in the Planet CCRMA testing repos...
>  -- Fernando
>
>
>  _______________________________________________
>  Fedora-music-list mailing list
>  Fedora-music-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-music-list
>

[Nicholas Manojlovic]

Packaging conventions and rules, I guess.

I like the idea of the Fedora music sig a lot, but it seems to be in a
half-half state. I realise I'm being ridiculously critical here, because I
haven't contributed. But it feels like it took the best things from CCRMA
and made them more 'generic' and not as specialised. I may be wrong.



On Wed, Apr 9, 2008 at 5:13 AM, Anthony Green <green(a)redhat.com&gt; wrote:

>  Nicholas Manojlovic wrote:
>
>  > I think I preferred it when Ardour was in the CCRMA repo. Not only was
>  > it quicker, I trust its been built with music in mind.
>  >
>  >
>  What do you mean by "built with music in mind"?  What else would we build
>  it for?
>
>  AG
>
>

[Greg DeKoenigsberg]

On Wed, 9 Apr 2008, Nicholas Manojlovic wrote:

>  Packaging conventions and rules, I guess.
>
>  I like the idea of the Fedora music sig a lot, but it seems to be in a
>  half-half state. I realise I'm being ridiculously critical here, because I
>  haven't contributed. But it feels like it took the best things from CCRMA
>  and made them more 'generic' and not as specialised. I may be wrong. 
Maybe this is a fair point.

Really, I first envisioned this as a way to help bring CCRMA and Fedora 
together.  Because the fact is, most of the CCRMA stuff should live in 
Fedora anyway.  But the fact that CCRMA requires the RT kernel and other 
non-standard stuff may make that difficult.

The real question, to me, is what about CCRMA makes it impossible to roll 
the CCRMA bits directly into Fedora proper?  And what can we do to fix 
those things?

This is the kind of thing we could/should be discussing on this list.

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 08:02 +1000, Nicholas Manojlovic wrote:
>  I think I preferred it when Ardour was in the CCRMA repo. Not only
> was
>  it quicker, I trust its been built with music in mind.  
I don't think there is any difference re: packaging between the Fedora
and Planet CCRMA repositories (if anything Fedora packages should be
better quality because of peer review, etc, etc). But that should not
translate normally into any audible or musical differences. 

The slower turn around is a direct consequence of how Fedora works and
is, I believe, unavoidable. 

-- Fernando


>  On Wed, Apr 9, 2008 at 4:24 AM, Fernando Lopez-Lezcano
>  <nando(a)ccrma.stanford.edu&gt; wrote:
>          On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
>          > ZC Miao wrote:
>          > > [quote]
>          > > Ardour 2.4 released
>          > > Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>          > > Well, its over a month later than expected, but Ardour 2.4
>          is finally
>          > > here. A respectable list of new features, many small
>          improvements and an
>          > > important set of bug fixes make up the news for this one.
>          Read more
>          > > below ...
>          > > [/quote]
>          > >
>          > > So, when will we get it in F8?
>          > >
>          >
>          > In F-8, I dunno, it is on its way to rawhide / F-9 beta now.
>          Considering that
>          > this not purely a bug fix release I'm not sure if we want to
>          release this as an
>          > update to F-8. What do others on this list think?
>          
>          
>          I would release it on Fedora 8. It has bug fixes and I think
>          other users
>          would probably appreciate having the latest.
>          
>          > You could grab the srpm from rawhide and build it for F-8,
>          and provide us with
>          > some feedback on it, that might help.
>          
>          
>          I'll probably try a release in the Planet CCRMA testing
>          repos...
>

[Fernando Lopez-Lezcano]

On Tue, 2008-04-08 at 18:21 -0400, Greg DeKoenigsberg wrote:
>  On Wed, 9 Apr 2008, Nicholas Manojlovic wrote:
>  
>  > Packaging conventions and rules, I guess.
>  >
>  > I like the idea of the Fedora music sig a lot, but it seems to be in a
>  > half-half state. I realise I'm being ridiculously critical here, because I
>  > haven't contributed. But it feels like it took the best things from CCRMA
>  > and made them more 'generic' and not as specialised. I may be wrong.
>  
>  Maybe this is a fair point.
>  
>  Really, I first envisioned this as a way to help bring CCRMA and Fedora 
>  together.  Because the fact is, most of the CCRMA stuff should live in 
>  Fedora anyway.  But the fact that CCRMA requires the RT kernel and other 
>  non-standard stuff may make that difficult. 
I don't think it is the kernel itself. After all I think all apps will
work fine on a stock Fedora kernel. They will not be able to run
reliably at low latencies but they will run. The "problem" (if there is
any) is a combination of many other factors. 

>  The real question, to me, is what about CCRMA makes it impossible to
> roll 
>  the CCRMA bits directly into Fedora proper?  And what can we do to fix 
>  those things? 
I can only bring my own point of view here. 

I don't think there is anything of a technical nature that prevents any
packages from moving (ignoring any non-free dependency stuff, of
course). 

Probably what is needed is more packagers that also use the stuff in day
to day music-making (BTW, I'm not complaining about current packagers),
and are commited to maintaining packages in the long term. And keeping
on top of new versions as they are released. That is what makes Planet
CCRMA tick. But packaging is notoriously unsexy stuff to do. I know. 

I currently don't see an advantage in maintaining packages _myself_ in
the Fedora environment as opposed to the Planet CCRMA system. It takes
far longer to do anything, or at least that is my perception. Maybe it
is because of lack of knowledge - I have not even caught up to the move
from plague to koji! (pretty pathetic, I know), but I don't have (m)any
cycles to burn on what I perceive to be non-essential stuff. In the time
it takes to discuss if we should release ardour 2.4 on f8 (I don't think
we ever saw 2.3.1, right?) to the masses I released a testing version
for fc6/7/8 in the Planet CCRMA repositories[*]. And I used to be a lot
more on top of releases (ie: Planet CCRMA moves quite slowly these
days :-). 

And to the point. Why not release ardour 2.4 on f8? Is it because it has
new features and those should be reserved to f9? Why? Users probably
want to use them _now_ and not wait till f9 comes out, at least the kind
of users I have (used to have?) on Planet CCRMA. Or is it because it may
be unstable? As if all the software in Fedora is stable, right? :-p

Do we want Fedora/Music to be rock stable? Or do we want a fast moving
music environment that keeps up to the latest and greatest? The later
would seem more "in tune" with Fedora itself and is what I used to do on
Planet CCRMA...

And to do it, how do we keep track of the latest and greatest and
release it fast?

-- Fernando

[*] nothing is for free of course. I tested ardour 2.4 on f8 briefly so
for all I know it may be broken everywhere else. Borrowed spec/etc from
the koji builder to stay synched with Fedora's...

[Greg DeKoenigsberg]

On Wed, 9 Apr 2008, Fernando Lopez-Lezcano wrote:

> >> Packaging conventions and rules, I guess.
> >>
> >> I like the idea of the Fedora music sig a lot, but it seems to be in a
> >> half-half state. I realise I'm being ridiculously critical here, because I
> >> haven't contributed. But it feels like it took the best things from CCRMA
> >> and made them more 'generic' and not as specialised. I may be wrong.
> >
> > Maybe this is a fair point.
> >
> > Really, I first envisioned this as a way to help bring CCRMA and Fedora
> > together.  Because the fact is, most of the CCRMA stuff should live in
> > Fedora anyway.  But the fact that CCRMA requires the RT kernel and other
> > non-standard stuff may make that difficult.
>
>  I don't think it is the kernel itself. After all I think all apps will 
>  work fine on a stock Fedora kernel. They will not be able to run 
>  reliably at low latencies but they will run. The "problem" (if there is 
>  any) is a combination of many other factors.
>
> > The real question, to me, is what about CCRMA makes it impossible to roll
> > the CCRMA bits directly into Fedora proper?  And what can we do to fix
> > those things?
>
>  I can only bring my own point of view here.
>
>  I don't think there is anything of a technical nature that prevents any
>  packages from moving (ignoring any non-free dependency stuff, of
>  course).
>
>  Probably what is needed is more packagers that also use the stuff in day
>  to day music-making (BTW, I'm not complaining about current packagers),
>  and are commited to maintaining packages in the long term. And keeping
>  on top of new versions as they are released. That is what makes Planet
>  CCRMA tick. But packaging is notoriously unsexy stuff to do. I know. 
Yep.  And yet, we've got hundreds of volunteers doing exactly that in the 
Fedora world.  There are many open questions about the quality of these 
packages, though.

>  I currently don't see an advantage in maintaining packages
> _myself_ in 
>  the Fedora environment as opposed to the Planet CCRMA system. It takes 
>  far longer to do anything, or at least that is my perception. Maybe it 
>  is because of lack of knowledge - I have not even caught up to the move 
>  from plague to koji! (pretty pathetic, I know), but I don't have (m)any 
>  cycles to burn on what I perceive to be non-essential stuff. 
This is a fair point.  And there's no advantage at all if the new system 
simply forces you to adopt a new system, when the old system worked 
perfectly well for you.

No, the only way there's benefit is if you get hands to help you maintain 
packages.

>  In the time it takes to discuss if we should release ardour 2.4 on f8
> (I 
>  don't think we ever saw 2.3.1, right?) to the masses I released a 
>  testing version for fc6/7/8 in the Planet CCRMA repositories[*]. And I 
>  used to be a lot more on top of releases (ie: Planet CCRMA moves quite 
>  slowly these days :-).
>
>  And to the point. Why not release ardour 2.4 on f8? Is it because it has
>  new features and those should be reserved to f9? Why? Users probably
>  want to use them _now_ and not wait till f9 comes out, at least the kind
>  of users I have (used to have?) on Planet CCRMA. Or is it because it may
>  be unstable? As if all the software in Fedora is stable, right? :-p 
Heh.

So again, there are tradeoffs that come with using Fedora itself.  One of 
those tradeoffs is accepting, or arguing about, a bunch of policies.  The 
alleged benefit for you, Nando, would be to cut your workload by a 
significant amount.  But that clearly isn't happening.

>  Do we want Fedora/Music to be rock stable? Or do we want a fast
> moving
>  music environment that keeps up to the latest and greatest? The later
>  would seem more "in tune" with Fedora itself and is what I used to do on
>  Planet CCRMA...
>
>  And to do it, how do we keep track of the latest and greatest and
>  release it fast? 
Good questions.

It may well be that CCRMA should continue to be fully independent, but 
have a much stronger base of Fedora packages to draw from, and Nando, when 
you see fit, you can supersede a Fedora package with a newer package in 
CCRMA.  That would be a pretty good outcome, too.

Basically: you're doing awesome work, maybe the best work in the Linux 
music space, and we at Fedora need to continue to find incremental ways to 
lighten your load without getting in your way.

How many CCRMA packages currently have Fedora analogues at this point, 
anyway?

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 10:34 -0400, Greg DeKoenigsberg wrote:
>  On Wed, 9 Apr 2008, Fernando Lopez-Lezcano wrote:
>  >> Really, I first envisioned this as a way to help bring CCRMA and Fedora
>  >> together.  Because the fact is, most of the CCRMA stuff should live in
>  >> Fedora anyway.  But the fact that CCRMA requires the RT kernel and other
>  >> non-standard stuff may make that difficult.
>  >
>  > I don't think it is the kernel itself. After all I think all apps will 
>  > work fine on a stock Fedora kernel. They will not be able to run 
>  > reliably at low latencies but they will run. The "problem" (if there is 
>  > any) is a combination of many other factors.
>  >
>  >> The real question, to me, is what about CCRMA makes it impossible to roll
>  >> the CCRMA bits directly into Fedora proper?  And what can we do to fix
>  >> those things?
>  >
>  > I can only bring my own point of view here.
>  >
>  > I don't think there is anything of a technical nature that prevents any
>  > packages from moving (ignoring any non-free dependency stuff, of
>  > course).
>  >
>  > Probably what is needed is more packagers that also use the stuff in day
>  > to day music-making (BTW, I'm not complaining about current packagers),
>  > and are commited to maintaining packages in the long term. And keeping
>  > on top of new versions as they are released. That is what makes Planet
>  > CCRMA tick. But packaging is notoriously unsexy stuff to do. I know.
>  
>  Yep.  And yet, we've got hundreds of volunteers doing exactly that in the 
>  Fedora world.  
That is good....

>  There are many open questions about the quality of these 
>  packages, though. 
At least the ones that I have looked at seem to be pretty good - but I
have not looked at really complicated stuff[*]. Of the ones the migrated
from Planet CCRMA I dare say they got better (less hacks I guess :-). 

>  > In the time it takes to discuss if we should release ardour 2.4
> on f8 (I 
>  > don't think we ever saw 2.3.1, right?) to the masses I released a 
>  > testing version for fc6/7/8 in the Planet CCRMA repositories[*]. And I 
>  > used to be a lot more on top of releases (ie: Planet CCRMA moves quite 
>  > slowly these days :-).
>  >
>  > And to the point. Why not release ardour 2.4 on f8? Is it because it has
>  > new features and those should be reserved to f9? Why? Users probably
>  > want to use them _now_ and not wait till f9 comes out, at least the kind
>  > of users I have (used to have?) on Planet CCRMA. Or is it because it may
>  > be unstable? As if all the software in Fedora is stable, right? :-p
>  
>  Heh.
>  
>  So again, there are tradeoffs that come with using Fedora itself.  One of 
>  those tradeoffs is accepting, or arguing about, a bunch of policies.  
I agree, comes with the territory. I hope I didn't sound too whiny. 

>  The alleged benefit for you, Nando, would be to cut your workload by
> a 
>  significant amount.  But that clearly isn't happening. 
Well, it _has_ happened, just not to the degree, or as fast as we
expected it to happen. Part of it may be that there are more options now
in terms of distributions and users have migrated over the years to
other distros, and some of those may be audio apps packagers as well. 

>  > Do we want Fedora/Music to be rock stable? Or do we want a fast
> moving
>  > music environment that keeps up to the latest and greatest? The later
>  > would seem more "in tune" with Fedora itself and is what I used to do on
>  > Planet CCRMA...
>  >
>  > And to do it, how do we keep track of the latest and greatest and
>  > release it fast?
>  
>  Good questions. 
Any answers from the rest of the audience?? Or comments? :-)

>  It may well be that CCRMA should continue to be fully independent,
> but 
>  have a much stronger base of Fedora packages to draw from,  
That has already happened I think, there's a lot of stuff that I used to
package in the, say, Fedora 1 or RedHat 9 days that now comes directly
from Fedora. You know, general purpose support packages that other
packages need to be able to build. Or even music related stuff like
Csound. 

>  and Nando, when 
>  you see fit, you can supersede a Fedora package with a newer package in 
>  CCRMA.  That would be a pretty good outcome, too.
>  
>  Basically: you're doing awesome work, maybe the best work in the Linux 
>  music space, and we at Fedora need to continue to find incremental ways to 
>  lighten your load without getting in your way.
>  
>  How many CCRMA packages currently have Fedora analogues at this point, 
>  anyway? 
Hmmm, I don't really know, I should run a script to see exactly what is
the status these days. But the packages that have migrated to Fedora
proper I try not to replicate in my repos (Ardour is an exception right
now). 

I forgot to add that we have extended Planet CCRMA to embrace CentOS
(ahem!) as well. Arnaud Gomes-do-Vale at IRCAM had been supporting that
option for a while (a fantastic job) and I finally came through and
installed plague and friends in our build server so that a build system
and shared svn repo for specs and all that is in place. So there's a lot
more help than before (for example the packaging for LV2 that I just
released was done by Arnaud). 

-- Fernando

[*] if you want to get a headache take a look at what I had to do to get
pd-extended built into subpackages for all the external collections....

[Dave Jones]

On Wed, Apr 09, 2008 at 10:34:14AM -0400, Greg DeKoenigsberg wrote:

>  >> Really, I first envisioned this as a way to help bring CCRMA
> and Fedora
>  >> together.  Because the fact is, most of the CCRMA stuff should live in
>  >> Fedora anyway.  But the fact that CCRMA requires the RT kernel and other
>  >> non-standard stuff may make that difficult.
>  >
>  > I don't think it is the kernel itself. After all I think all apps will 
>  > work fine on a stock Fedora kernel. They will not be able to run 
>  > reliably at low latencies but they will run. The "problem" (if there is 
>  > any) is a combination of many other factors. 
The -rt changes continue to trickle upstream.  hopefully eventually this
problem will become moot.

>  > Probably what is needed is more packagers that also use the
> stuff in day
>  > to day music-making (BTW, I'm not complaining about current packagers),
>  > and are commited to maintaining packages in the long term. And keeping
>  > on top of new versions as they are released. That is what makes Planet
>  > CCRMA tick. But packaging is notoriously unsexy stuff to do. I know.
>  
>  Yep.  And yet, we've got hundreds of volunteers doing exactly that in the 
>  Fedora world.  There are many open questions about the quality of these 
>  packages, though. 
Would it help any if somone else stepped up and started maintaining analogs
of ccrma packages in 'core' ?  I'd probably be interested in finding time
to maintain a few of them myself if this made peoples lives easier.
I've held off from proposing package reviews of several apps (not just
music apps) because someone is maintaining rpms in another repo

>  It may well be that CCRMA should continue to be fully independent,
> but 
>  have a much stronger base of Fedora packages to draw from, and Nando, when 
>  you see fit, you can supersede a Fedora package with a newer package in 
>  CCRMA.  That would be a pretty good outcome, too. 
I'm beginning to wonder if 3rd party repos are doing us more harm
than good in the long run.
The reason I bring this up is because after several discussions with
people yesterday here at the Linux Foundation collaboration summit,
I heard things like..

"I prefer ubuntu/debian because it has more packages."
"true, but what packages are you missing from Fedora?"
"xyz"
"Oh, we have that packaged but it's in repo z"

A lot of users won't go hunting for extra repositories.
If it isn't in the repos that Fedora comes bundled with, to them, it doesn't
exist
in Fedora.

And for those that are aware of 3rd party repos, there seems to be a reluctance
to adding them to avoid the infamous "rpm hell" with conflicting deps
between repos.

I'm sure this small sample of users isn't representative, but it's
definitly holding some users back.   Personally, I know I've given up
after finding something isn't packaged in Fedora on many occasions,
and it pains me to say it, but it's sometimes been quicker/easier
to go download a binary of the same opensource app for my mac than it
is to get the same thing running under Fedora.

Anyway, hyperbole over.  How can we improve the situation?

>  Basically: you're doing awesome work, maybe the best work in the
> Linux 
>  music space, and we at Fedora need to continue to find incremental ways to 
>  lighten your load without getting in your way.
>  How many CCRMA packages currently have Fedora analogues at this point, 
>  anyway? 
The apps shouldn't pose too much of a problem to get merged, but I'm wondering
how things like jack fit into the new world order of pulseaudio.
I guess Nando already has to deal with this somehow, so maybe it's
already a solved problem, but things like this and the kernel are the
only technical hurdles afaics?

In my utopian world, I'd love to see ccrma just become a spin of
the main fedora. Allowing people who want a more multi-purpose
install to also install those same packages without the hassle
of additional repos.

	Dave

-- 
http://www.codemonkey.org.uk

[Greg DeKoenigsberg]

On Wed, 9 Apr 2008, Fernando Lopez-Lezcano wrote:

> > Yep.  And yet, we've got hundreds of volunteers doing exactly
> that in the
> > Fedora world.
>
>  That is good....
>
> > There are many open questions about the quality of these
> > packages, though.
>
>  At least the ones that I have looked at seem to be pretty good - but I
>  have not looked at really complicated stuff[*]. Of the ones the migrated
>  from Planet CCRMA I dare say they got better (less hacks I guess :-). 
Heh.  Well, that's the benefit of all those heinous guidelines.  :)

> > The alleged benefit for you, Nando, would be to cut your workload
> by a
> > significant amount.  But that clearly isn't happening.
>
>  Well, it _has_ happened, just not to the degree, or as fast as we
>  expected it to happen. Part of it may be that there are more options now
>  in terms of distributions and users have migrated over the years to
>  other distros, and some of those may be audio apps packagers as well. 
Right.

So this is a conversation that I'm having, in some form or another, all 
across the Fedora universe.  Step 1, for me, was to make sure that Fedora 
functioned as an actual *community*.  Mission accomplished, more or less. 
So step 2 is basically marketing, and showing everybody how awesome Fedora 
and Fedora-related projects can be.

The absence of CCRMA from that survey that got passed around the 
ccrma-list a coupld of months back really stuck in my craw, I must say. 
But that's our fault, to some degree.

So maybe the question is, how do we promote CCRMA?

I think one way we promote it by noting who does the work.  "Maintained by 
professors at Stanford" has got to be a pretty big selling point.

I know that a lot of people don't have much stomach for this kind of work, 
but it's important, especially in community projects, to generate 
excitement around excellent work.  Nobody puts Nando in a corner.  :)

> > It may well be that CCRMA should continue to be fully
> independent, but
> > have a much stronger base of Fedora packages to draw from,
>
>  That has already happened I think, there's a lot of stuff that I used to
>  package in the, say, Fedora 1 or RedHat 9 days that now comes directly
>  from Fedora. You know, general purpose support packages that other
>  packages need to be able to build. Or even music related stuff like
>  Csound. 
We can thank OLPC for that.

>  I forgot to add that we have extended Planet CCRMA to embrace CentOS
>
>  (ahem!) as well. Arnaud Gomes-do-Vale at IRCAM had been supporting that 
>  option for a while (a fantastic job) and I finally came through and 
>  installed plague and friends in our build server so that a build system 
>  and shared svn repo for specs and all that is in place. So there's a lot 
>  more help than before (for example the packaging for LV2 that I just 
>  released was done by Arnaud). 
Honestly, I think that this is a big advantage for Fedora.  The 
CentOS/Fedora partnership is becoming quite strong indeed, since the goals 
are so similar.  No worries on this end.  :)

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Hector Centeno]

Hi,

I just would like to share my point of view as a CCRMA user. One of
the main reasons I moved from Debian based distros to Fedora-CCRMA was
because of the fast availability of the latest versions of audio and
music software. I think that in this field (audio/music) to have the
"latest and greatest" is of great benefit since many of this apps are
under heavy development and there are many improvements from one
version to the other. When I used Debian based distros I had to
constantly build my own applications so Fedora-CCRMA represented a big
time saver (so I could be more of a composer using Linux than a hacker
trying to use Linux). When I found about CCRMA moving to the main
Fedora repos I thought it was a great idea since it would make things
easier to Fernando. But now I find myself having to do the same app
building I was doing in Debian and realizing that at the end it seems
that all the "official" distro repositories, in their efforts of being
"stable" (I agree with Fernando: how stable really Fedora is) become a
big barrier for quick change and development.

I don't see having external repos as an inconvenient thing and in the
case of CCRMA (which I've been using on and off since Fedora 2) I
never had any dependency "hell" as with other external repos since
Fernando seems to always keep his packages totally compatible with the
main Fedora repos and even with some important external ones like
Livna.

I support the idea of having newer versions of pakages in the CCRMA
repos that supersede the ones in the Fedora repos and also agree that
Fernando should get as many volunteers as possible to help him with
the packaging (myself I've been trying to make time for it since I
would like to take care of Csound and knowing that I wouldn't have to
deal with the lengthy official Fedora processes makes it more
appealing). This way then there are two options: for the user
comfortable with slow and "stable" releases there is main Fedora, for
the user needing bleeding edge there is CCRMA.

Just my two cents.


Hector



On Wed, Apr 9, 2008 at 11:07 AM, Dave Jones <davej(a)redhat.com&gt; wrote:
>  On Wed, Apr 09, 2008 at 10:34:14AM -0400, Greg DeKoenigsberg wrote:
>
>    > >> Really, I first envisioned this as a way to help bring CCRMA and Fedora
>    > >> together.  Because the fact is, most of the CCRMA stuff should live in
>    > >> Fedora anyway.  But the fact that CCRMA requires the RT kernel and other
>    > >> non-standard stuff may make that difficult.
>    > >
>    > > I don't think it is the kernel itself. After all I think all apps will
>    > > work fine on a stock Fedora kernel. They will not be able to run
>    > > reliably at low latencies but they will run. The "problem" (if
> there is
>    > > any) is a combination of many other factors.
>
>   The -rt changes continue to trickle upstream.  hopefully eventually this
>   problem will become moot.
>
>
>    > > Probably what is needed is more packagers that also use the stuff in day
>    > > to day music-making (BTW, I'm not complaining about current packagers),
>    > > and are commited to maintaining packages in the long term. And keeping
>    > > on top of new versions as they are released. That is what makes Planet
>    > > CCRMA tick. But packaging is notoriously unsexy stuff to do. I know.
>    >
>    > Yep.  And yet, we've got hundreds of volunteers doing exactly that in the
>    > Fedora world.  There are many open questions about the quality of these
>    > packages, though.
>
>   Would it help any if somone else stepped up and started maintaining analogs
>   of ccrma packages in 'core' ?  I'd probably be interested in finding time
>   to maintain a few of them myself if this made peoples lives easier.
>   I've held off from proposing package reviews of several apps (not just
>   music apps) because someone is maintaining rpms in another repo
>
>
>    > It may well be that CCRMA should continue to be fully independent, but
>    > have a much stronger base of Fedora packages to draw from, and Nando, when
>    > you see fit, you can supersede a Fedora package with a newer package in
>    > CCRMA.  That would be a pretty good outcome, too.
>
>   I'm beginning to wonder if 3rd party repos are doing us more harm
>   than good in the long run.
>   The reason I bring this up is because after several discussions with
>   people yesterday here at the Linux Foundation collaboration summit,
>   I heard things like..
>
>   "I prefer ubuntu/debian because it has more packages."
>   "true, but what packages are you missing from Fedora?"
>   "xyz"
>   "Oh, we have that packaged but it's in repo z"
>
>   A lot of users won't go hunting for extra repositories.
>   If it isn't in the repos that Fedora comes bundled with, to them, it doesn't
> exist
>   in Fedora.
>
>   And for those that are aware of 3rd party repos, there seems to be a reluctance
>   to adding them to avoid the infamous "rpm hell" with conflicting deps
>   between repos.
>
>   I'm sure this small sample of users isn't representative, but it's
>   definitly holding some users back.   Personally, I know I've given up
>   after finding something isn't packaged in Fedora on many occasions,
>   and it pains me to say it, but it's sometimes been quicker/easier
>   to go download a binary of the same opensource app for my mac than it
>   is to get the same thing running under Fedora.
>
>   Anyway, hyperbole over.  How can we improve the situation?
>
>
>    > Basically: you're doing awesome work, maybe the best work in the Linux
>    > music space, and we at Fedora need to continue to find incremental ways to
>    > lighten your load without getting in your way.
>    > How many CCRMA packages currently have Fedora analogues at this point,
>    > anyway?
>
>   The apps shouldn't pose too much of a problem to get merged, but I'm wondering
>   how things like jack fit into the new world order of pulseaudio.
>   I guess Nando already has to deal with this somehow, so maybe it's
>   already a solved problem, but things like this and the kernel are the
>   only technical hurdles afaics?
>
>   In my utopian world, I'd love to see ccrma just become a spin of
>   the main fedora. Allowing people who want a more multi-purpose
>   install to also install those same packages without the hassle
>   of additional repos.
>
>          Dave
>
>   --
>   http://www.codemonkey.org.uk
>
>
>
>   _______________________________________________
>   Fedora-music-list mailing list
>   Fedora-music-list(a)redhat.com
>   http://www.redhat.com/mailman/listinfo/fedora-music-list
>

[Greg DeKoenigsberg]

On Wed, 9 Apr 2008, Dave Jones wrote:

>  Would it help any if somone else stepped up and started maintaining
> analogs
>  of ccrma packages in 'core' ?  I'd probably be interested in finding time
>  to maintain a few of them myself if this made peoples lives easier.
>  I've held off from proposing package reviews of several apps (not just
>  music apps) because someone is maintaining rpms in another repo 
I'm sure it would.

>  > It may well be that CCRMA should continue to be fully
> independent, but
>  > have a much stronger base of Fedora packages to draw from, and Nando, when
>  > you see fit, you can supersede a Fedora package with a newer package in
>  > CCRMA.  That would be a pretty good outcome, too.
>
>  I'm beginning to wonder if 3rd party repos are doing us more harm than 
>  good in the long run. The reason I bring this up is because after 
>  several discussions with people yesterday here at the Linux Foundation 
>  collaboration summit, I heard things like..
>
>  "I prefer ubuntu/debian because it has more packages."
>  "true, but what packages are you missing from Fedora?"
>  "xyz"
>  "Oh, we have that packaged but it's in repo z"
>
>  A lot of users won't go hunting for extra repositories. If it isn't in 
>  the repos that Fedora comes bundled with, to them, it doesn't exist in 
>  Fedora. 
We just need to assess the reasons for these separations.  Most of these 
issues have to do with The Repo That Must Not Be Named, and that's a 
difficult problem to solve.

>  And for those that are aware of 3rd party repos, there seems to be a
>
>  reluctance to adding them to avoid the infamous "rpm hell" with 
>  conflicting deps between repos. 
Yeah.  That is a problem, yes.

>  I'm sure this small sample of users isn't representative, but
> it's 
>  definitly holding some users back.  Personally, I know I've given up 
>  after finding something isn't packaged in Fedora on many occasions, and 
>  it pains me to say it, but it's sometimes been quicker/easier to go 
>  download a binary of the same opensource app for my mac than it is to 
>  get the same thing running under Fedora. 
SPLITTER!

>  The apps shouldn't pose too much of a problem to get merged, but
> I'm 
>  wondering how things like jack fit into the new world order of 
>  pulseaudio. I guess Nando already has to deal with this somehow, so 
>  maybe it's already a solved problem, but things like this and the kernel 
>  are the only technical hurdles afaics?
>
>  In my utopian world, I'd love to see ccrma just become a spin of
>  the main fedora. Allowing people who want a more multi-purpose
>  install to also install those same packages without the hassle
>  of additional repos. 
This has always been, and continues to be, my end goal.  In Nando's case, 
and doubtless in other cases, it's a matter of "swallowing the pig whole," 
so to speak.  Until we can provide/demonstrate Nando enough value in the 
Fedora process to incur the switching cost, he will (rightly) do things 
the way he needs to do them to keep moving forward.

So the first step, methinks, is to find more packagers.  Nando, if you can 
actually get some numbers on how many packages are unique to CCRMA, that 
would be a great start.

Now, if you'll excuse me, I've got a couple of potential packagers I'm 
going to chase down.  :)

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Anthony Green]

Hi Hector,

Hector Centeno wrote:
>  I support the idea of having newer versions of pakages in the CCRMA
>  repos that supersede the ones in the Fedora repos and also agree that
>  Fernando should get as many volunteers as possible to help him with
>  the packaging (myself I've been trying to make time for it since I
>  would like to take care of Csound and knowing that I wouldn't have to
>  deal with the lengthy official Fedora processes makes it more
>  appealing).  
The lengthy official Fedora processes are only lengthy for the initial

package review.  Once it's in, it can be updated as quickly and as often 
as the maintainers desire.  If, for some reason, Fedora is behind on 
something, simply file a bugzilla ticket.   This process works.
>  This way then there are two options: for the user
>  comfortable with slow and "stable" releases there is main Fedora, for
>  the user needing bleeding edge there is CCRMA.
>
>     
My speculation is that nobody is really interested in slow and stable 
releases of audio software -- just ones that don't break compatibility 
(my ardour 2.2 project should work with ardour 2.4, etc).

If you are already building your own packages, why not co-maintain some 
set of packages in Fedora?

AG

[Hans de Goede]

Dave Jones wrote:
>  On Wed, Apr 09, 2008 at 10:34:14AM -0400, Greg DeKoenigsberg wrote:
>  
>   > >> Really, I first envisioned this as a way to help bring CCRMA and Fedora
>   > >> together.  Because the fact is, most of the CCRMA stuff should live in
>   > >> Fedora anyway.  But the fact that CCRMA requires the RT kernel and other
>   > >> non-standard stuff may make that difficult.
>   > >
>   > > I don't think it is the kernel itself. After all I think all apps will 
>   > > work fine on a stock Fedora kernel. They will not be able to run 
>   > > reliably at low latencies but they will run. The "problem" (if there
> is 
>   > > any) is a combination of many other factors.
>  
>  The -rt changes continue to trickle upstream.  hopefully eventually this
>  problem will become moot.
>  
>   > > Probably what is needed is more packagers that also use the stuff in day
>   > > to day music-making (BTW, I'm not complaining about current packagers),
>   > > and are commited to maintaining packages in the long term. And keeping
>   > > on top of new versions as they are released. That is what makes Planet
>   > > CCRMA tick. But packaging is notoriously unsexy stuff to do. I know.
>   > 
>   > Yep.  And yet, we've got hundreds of volunteers doing exactly that in the 
>   > Fedora world.  There are many open questions about the quality of these 
>   > packages, though.
>  
>  Would it help any if somone else stepped up and started maintaining analogs
>  of ccrma packages in 'core' ?  I'd probably be interested in finding time
>  to maintain a few of them myself if this made peoples lives easier. 
Yes,

I've been busy pushing ccrma packages into Fedora proper in the past, but I've 
stopped doing that due to lack of time (just keeping 200+ packages up to date 
actually takes quite an amount of time).

>  I've held off from proposing package reviews of several apps (not
> just
>  music apps) because someone is maintaining rpms in another repo
>  
I don't think thats a very good argument, if it can be in Fedora, it should be 
in Fedora, trying to work with existing repo's on this is a good thing of 
course, but our end users having Fedora + some patent / non free encumbered 
repo should be all they need.

>   > It may well be that CCRMA should continue to be fully
> independent, but 
>   > have a much stronger base of Fedora packages to draw from, and Nando, when 
>   > you see fit, you can supersede a Fedora package with a newer package in 
>   > CCRMA.  That would be a pretty good outcome, too.
>  
>  I'm beginning to wonder if 3rd party repos are doing us more harm
>  than good in the long run.
>  The reason I bring this up is because after several discussions with
>  people yesterday here at the Linux Foundation collaboration summit,
>  I heard things like..
>  
>  "I prefer ubuntu/debian because it has more packages."
>  "true, but what packages are you missing from Fedora?"
>  "xyz"
>  "Oh, we have that packaged but it's in repo z"
>   
Exactly the argument I was trying to make above, we need less repos!

>  I'm sure this small sample of users isn't representative, but
> it's
>  definitly holding some users back.   Personally, I know I've given up
>  after finding something isn't packaged in Fedora on many occasions,
>  and it pains me to say it, but it's sometimes been quicker/easier
>  to go download a binary of the same opensource app for my mac than it
>  is to get the same thing running under Fedora.
>  
>  Anyway, hyperbole over.  How can we improve the situation?
>   
Well if you encounter such a package, atleast at it to the wishlist:
http://fedoraproject.org/wiki/PackageMaintainers/WishList

Also this is a clear example of the fact that we need _more_ packagers. So 
first of all we need to put a gag in the mouth of those we keep saying their 
aren't any interesting things left to package, and then we need to mayybe start 
something like an active marketing campaign that we're looking for packagers, 
and together with that start up some kind of mentoring group which works one 
guiding new packages on there first steps. Which reminds me, we haven't been 
promoting any contributers to mentor status for a while, this is another thing
we need to fix!

>   > Basically: you're doing awesome work, maybe the best work
> in the Linux 
>   > music space, and we at Fedora need to continue to find incremental ways to 
>   > lighten your load without getting in your way.
>   > How many CCRMA packages currently have Fedora analogues at this point, 
>   > anyway?
>  
>  The apps shouldn't pose too much of a problem to get merged, but I'm wondering
>  how things like jack fit into the new world order of pulseaudio.
>  I guess Nando already has to deal with this somehow, so maybe it's
>  already a solved problem, but things like this and the kernel are the
>  only technical hurdles afaics?
>  
>  In my utopian world, I'd love to see ccrma just become a spin of
>  the main fedora. 
I believe this is easily feasible given enough manpower, most ccrma packages 
are pretty clean, they just need someone to push them through the review 
process, then the biggest hurdle left is ... the rt-kernel.

Well since I seem to be talking to the right person now, I know you hate this 
question, but ... how strongly would you object to having an rt kernel variant 
within Fedora?

Regards,

Hans

[Greg DeKoenigsberg]

On Wed, 9 Apr 2008, Hans de Goede wrote:

>  Well since I seem to be talking to the right person now, I know you
> hate this 
>  question, but ... how strongly would you object to having an rt kernel 
>  variant within Fedora? 
LOL.  I asked this question two years ago.  I doubt the answer has 
changed.  :)

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Hans de Goede]

Fernando Lopez-Lezcano wrote:
>  On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
> > ZC Miao wrote:
> >> [quote]
> >> Ardour 2.4 released
> >> Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
> >> Well, its over a month later than expected, but Ardour 2.4 is finally
> >> here. A respectable list of new features, many small improvements and an
> >> important set of bug fixes make up the news for this one. Read more
> >> below ...
> >> [/quote]
> >>
> >> So, when will we get it in F8?
> >>
> > In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering that 
> > this not purely a bug fix release I'm not sure if we want to release this as an 
> > update to F-8. What do others on this list think?
>  
>  I would release it on Fedora 8. It has bug fixes and I think other users
>  would probably appreciate having the latest. 
>  
> > You could grab the srpm from rawhide and build it for F-8, and provide us with 
> > some feedback on it, that might help.
>  
>  I'll probably try a release in the Planet CCRMA testing repos... 
Since there seems much demand for this I've just pushed a build of ardour-2.4 
to the F-8 updates-testing repo (it will show up there with the next update of 
the update repositories). Please give this a thorough testing, then in a couple 
of weeks I'll push it to the regular updates repo.

Regards,

Hans

[Dave Jones]

On Wed, Apr 09, 2008 at 07:42:02PM +0200, Hans de Goede wrote:
>  I believe this is easily feasible given enough manpower, most ccrma
> packages 
>  are pretty clean, they just need someone to push them through the review 
>  process, then the biggest hurdle left is ... the rt-kernel.
>  
>  Well since I seem to be talking to the right person now, I know you hate this 
>  question, but ... how strongly would you object to having an rt kernel variant 
>  within Fedora? 
Not incredibly keen tbh.  I'd sooner just add -rt to the regular kernel package
and suck it up, but that obviously takes us further from our 'upstream first'
mantra.

Ingo & Thomas are getting sizable chunks of it merged upstream, but I don't think
we'll be seeing it all merged soon, but then again, F10 is quite a ways off,
and with a few more kernel releases, who knows.
Depends how objectionable the remaining bits are I guess.
Given that so many people are now distributing products based on this work, getting
it all in mainline is obviously important, and there's no shortage of manpower
helping drive it there.

All this said, I personally haven't hit any issues with things like MIDI in
Fedora where the -rt kernel would have helped me.  Maybe my gear is special,
but latency between me hitting a key on a synth and having that note show
up in rosegarden, and a sound being created is well below perceivable.
I'm interested to hear any test cases you guys may have that justify why
you need -rt.  Right now the guys working on that stuff typically have a
bunch of 'boring' test cases more tailored towards replicating situations
like stock trades and the like.  If we can construct additional use-cases
I'm sure Ingo, Thomas & co would be very interested to hear about them.
Especially if these cases are triggering different latency paths.

	Dave

-- 
http://www.codemonkey.org.uk

[Arnaud Gomes-do-Vale]

Hi,

First let me introduce myself, as I think I have never posted to this
list. I have been rebuilding a few audio packages on CentOS 4 and 5
for a couple of years. As Fernando mentioned earlier, I ended up
submitting patches and a few new packages to Planet CCRMA.

Anthony Green <green(a)redhat.com&gt; writes:

>  My speculation is that nobody is really interested in slow and
> stable
>  releases of audio software -- just ones that don't break compatibility
>  (my ardour 2.2 project should work with ardour 2.4, etc).
>  
>  If you are already building your own packages, why not co-maintain
>  some set of packages in Fedora? 
As far as I can tell, this point of view (which I fully agree with) is
very much the opposite of EPEL's goal of stability. So for me at
least, this means contributing directly to Fedora is not really an
option. I mean, I could do it, but I wouldn't get much back if I have
to build my own packages anyway. :-)

That being said, the situation is much better now that it was, say,
two years ago, as Linux audio is really getting mature; however many
parts of a current Linux audio installation are still moving
targets. Building up-to-date audio packages on a distro 6-12 months
old is not trivial. I had to build some parts of GNOME that would
probably not fit into EPEL for packaging patchage on CentOS 5, for
instance. And a reasonably complete audio package set pretty much
requires 2 or 3 different versions of wxGTK.

-- 
Arnaud

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 13:48 -0400, Greg DeKoenigsberg wrote:
>  On Wed, 9 Apr 2008, Hans de Goede wrote:
>  
>  > Well since I seem to be talking to the right person now, I know you hate this 
>  > question, but ... how strongly would you object to having an rt kernel 
>  > variant within Fedora?
>  
>  LOL.  I asked this question two years ago.  I doubt the answer has 
>  changed.  :) 
But the situation HAS changed. A LOT. There is now (or is going to be) a
realtime kernel in _RedHat Enterprise_ of all places. If it is good and
stable for RHEL why wouldn't it be good for Fedora? (but I miss the
answer you got a while back which could have been completely
different). 

In the latest spins of my rt kernel I have actually used the patch set
of the RHEL beta realtime kernel _and_ the patch set of the latest
Fedora kernels [NOT fun to integrate!], with very good results, in fact
much better than the stock Ingo patches - don't know exactly why - and
the first decent 2.6.24.x realtime kernels I've tested. 

So there you are. The answer should be different, right? :-P

-- Fernando

[wow, this list got very lively in a second...]

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 15:58 -0400, Dave Jones wrote:
>  On Wed, Apr 09, 2008 at 07:42:02PM +0200, Hans de Goede wrote:
>   > I believe this is easily feasible given enough manpower, most ccrma packages 
>   > are pretty clean, they just need someone to push them through the review 
>   > process, then the biggest hurdle left is ... the rt-kernel.
>   > 
>   > Well since I seem to be talking to the right person now, I know you hate this 
>   > question, but ... how strongly would you object to having an rt kernel variant 
>   > within Fedora?
>  
>  Not incredibly keen tbh.  I'd sooner just add -rt to the regular kernel package
>  and suck it up, but that obviously takes us further from our 'upstream first'
>  mantra.
>  
>  Ingo & Thomas are getting sizable chunks of it merged upstream, but I don't
> think
>  we'll be seeing it all merged soon, but then again, F10 is quite a ways off,
>  and with a few more kernel releases, who knows.
>  Depends how objectionable the remaining bits are I guess.
>  Given that so many people are now distributing products based on this work, getting
>  it all in mainline is obviously important, and there's no shortage of manpower
>  helping drive it there.
>  
>  All this said, I personally haven't hit any issues with things like MIDI in
>  Fedora where the -rt kernel would have helped me.  Maybe my gear is special,
>  but latency between me hitting a key on a synth and having that note show
>  up in rosegarden, and a sound being created is well below perceivable. 
And that would be how many milliseconds?

Can you run with 3 to 5 milliseconds latency without xruns on a loaded
system with the stock kernel? With the right hardware the answer is
probably yes, most of the time. The problem is the small percentage of
frames where you _do_ get an xrun and the click that goes with it. It
could be nobody notices it, it could be it actually ruins the concert or
recording session. 

What could seem below the perception level to you (caveat: I don't know
if you are a musician and what instrument you play) may bother a
professional percussionist using the computer as an instrument. It all
depends on your demands as a performer. 

>  I'm interested to hear any test cases you guys may have that
> justify why
>  you need -rt.  
Besides realtime performance, all the audio-over-the-network being done
at CCRMA needs it (see: http://ccrma.stanford.edu/groups/soundwire/).

This is, in a nutshell, multichannel (between 4 and 8 channels)
non-compressed high quality bidirectional audio being sent between 2 or
3 geographically separate locations to create a virtual concert hall and
jam session or concert. You don't want to add _any_ latency to the one
that speed of light already gives us :-) We routinely run at 64 frames
(or 128 if the links are not good). The stock Fedora kernel is just not
good enough although I'm sure it is getting better all the time. 

>  Right now the guys working on that stuff typically have a
>  bunch of 'boring' test cases more tailored towards replicating situations
>  like stock trades and the like.  If we can construct additional use-cases
>  I'm sure Ingo, Thomas & co would be very interested to hear about them.
>  Especially if these cases are triggering different latency paths. 
The apps being worked on at CCRMA (jacktrip) would touch both the
network drivers and drivers for pro audio cards. Probably disk as well
if the same host is being used to record the performance in Ardour. 

-- Fernando

[Dave Jones]

On Wed, Apr 09, 2008 at 02:24:34PM -0700, Fernando Lopez-Lezcano wrote:
>  
>  On Wed, 2008-04-09 at 13:48 -0400, Greg DeKoenigsberg wrote:
>  > On Wed, 9 Apr 2008, Hans de Goede wrote:
>  > 
>  > > Well since I seem to be talking to the right person now, I know you hate this 
>  > > question, but ... how strongly would you object to having an rt kernel 
>  > > variant within Fedora?
>  > 
>  > LOL.  I asked this question two years ago.  I doubt the answer has 
>  > changed.  :)
>  
>  But the situation HAS changed. A LOT. There is now (or is going to be) a
>  realtime kernel in _RedHat Enterprise_ of all places. If it is good and
>  stable for RHEL why wouldn't it be good for Fedora? 
Largely a manpower thing.  We have staff we can throw at RHEL projects.
Fedora, not so much.  Supporting an extra kernel variant is a big deal.
Given how understaffed the Fedora kernel team is in comparison to the
workload dealing with incoming bugs etc, it's not something we should
just do and hope for the best.   Even with the recent growth within
our team, we're still totally buried with stuff to do with the non-rt kernel.

>  In the latest spins of my rt kernel I have actually used the patch
> set
>  of the RHEL beta realtime kernel _and_ the patch set of the latest
>  Fedora kernels [NOT fun to integrate!] 
That's also an additional reason why we shy away from it for Fedora.
Fedora needs to be lightweight enough that we can quickly move to newer
upstream releases.  We lost a lot of agility when we were carrying Xen
for exactly the same reason.  And the idea of 'well have kernel-rt be
based on an earlier version' doesn't fly because then userspace has to
deal with two possible environments (Another case where Xen burned us).

	Dave

-- 
http://www.codemonkey.org.uk

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 17:40 -0400, Dave Jones wrote:
>  On Wed, Apr 09, 2008 at 02:24:34PM -0700, Fernando Lopez-Lezcano
> wrote:
>   > 
>   > On Wed, 2008-04-09 at 13:48 -0400, Greg DeKoenigsberg wrote:
>   > > On Wed, 9 Apr 2008, Hans de Goede wrote:
>   > > 
>   > > > Well since I seem to be talking to the right person now, I know you hate
> this 
>   > > > question, but ... how strongly would you object to having an rt kernel 
>   > > > variant within Fedora?
>   > > 
>   > > LOL.  I asked this question two years ago.  I doubt the answer has 
>   > > changed.  :)
>   > 
>   > But the situation HAS changed. A LOT. There is now (or is going to be) a
>   > realtime kernel in _RedHat Enterprise_ of all places. If it is good and
>   > stable for RHEL why wouldn't it be good for Fedora?
>  
>  Largely a manpower thing.  We have staff we can throw at RHEL projects.
>  Fedora, not so much.  
Yeah, sure, easy to understand (same here :-)
-- Fernando


>  Supporting an extra kernel variant is a big deal.
>  Given how understaffed the Fedora kernel team is in comparison to the
>  workload dealing with incoming bugs etc, it's not something we should
>  just do and hope for the best.   Even with the recent growth within
>  our team, we're still totally buried with stuff to do with the non-rt kernel.
>  
>   > In the latest spins of my rt kernel I have actually used the patch set
>   > of the RHEL beta realtime kernel _and_ the patch set of the latest
>   > Fedora kernels [NOT fun to integrate!]
>  
>  That's also an additional reason why we shy away from it for Fedora.
>  Fedora needs to be lightweight enough that we can quickly move to newer
>  upstream releases.  We lost a lot of agility when we were carrying Xen
>  for exactly the same reason.  And the idea of 'well have kernel-rt be
>  based on an earlier version' doesn't fly because then userspace has to
>  deal with two possible environments (Another case where Xen burned us).

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 11:23 -0400, Greg DeKoenigsberg wrote:
>  On Wed, 9 Apr 2008, Fernando Lopez-Lezcano wrote:
>  >> The alleged benefit for you, Nando, would be to cut your workload by a
>  >> significant amount.  But that clearly isn't happening.
>  >
>  > Well, it _has_ happened, just not to the degree, or as fast as we
>  > expected it to happen. Part of it may be that there are more options now
>  > in terms of distributions and users have migrated over the years to
>  > other distros, and some of those may be audio apps packagers as well.
>  
>  Right.
>  
>  So this is a conversation that I'm having, in some form or another, all 
>  across the Fedora universe.  Step 1, for me, was to make sure that Fedora 
>  functioned as an actual *community*.  Mission accomplished, more or less. 
>  So step 2 is basically marketing, and showing everybody how awesome Fedora 
>  and Fedora-related projects can be.
>  
>  The absence of CCRMA from that survey that got passed around the 
>  ccrma-list a coupld of months back really stuck in my craw, I must say.  
Hmmm, survey??

>  But that's our fault, to some degree.
>  
>  So maybe the question is, how do we promote CCRMA?
>  
>  I think one way we promote it by noting who does the work.  "Maintained by 
>  professors at Stanford" has got to be a pretty big selling point. 
I'm not into marketing but that one does not quite excite me... :-)

Maybe: "a system that works from people that use it", but then what do
we do when the system does not work? Or "providing a working low latency
sound and music environment since 2001", but then again sometimes things
just don't work, see, I'm not good at marketing :-) 

>  I know that a lot of people don't have much stomach for this kind
> of work, 
>  but it's important, especially in community projects, to generate 
>  excitement around excellent work.  
I guess the time comes when we have to turn on to marketing? Arghh...
How much marketing have I done? One initial post to the cmdist mailing
list at CCRMA in 2001 and then mostly word of mouth. Every once in a
while the inevitable "which one is the best distro for audio and music"
comes up in the linux audio lists and if no one suggests Planet CCRMA
then I speak up (a little). 

More to say, but it is getting late (I'm right now in Berlin of all
places, teaching for a few months at TU-Berlin's electronic music
studio, just got here last Friday). 

Nighty night...

-- Fernando

[Dave Jones]

On Wed, Apr 09, 2008 at 02:40:04PM -0700, Fernando Lopez-Lezcano wrote:

>  > All this said, I personally haven't hit any issues with
> things like MIDI in
>  > Fedora where the -rt kernel would have helped me.  Maybe my gear is special,
>  > but latency between me hitting a key on a synth and having that note show
>  > up in rosegarden, and a sound being created is well below perceivable.
>  
>  And that would be how many milliseconds? 
I honestly couldn't say (it's been some time, and I'm a few thousand miles
from home right now).

>  What could seem below the perception level to you (caveat: I
> don't know
>  if you are a musician and what instrument you play) may bother a
>  professional percussionist using the computer as an instrument. It all
>  depends on your demands as a performer.  
"musician" may be stretching my abilities somewhat :)
But yes, I understand that I'm probably not pushing things perhaps as
far as some others may be.

>  Besides realtime performance, all the audio-over-the-network being
> done
>  at CCRMA needs it (see: http://ccrma.stanford.edu/groups/soundwire/).
>  
>  This is, in a nutshell, multichannel (between 4 and 8 channels)
>  non-compressed high quality bidirectional audio being sent between 2 or
>  3 geographically separate locations to create a virtual concert hall and
>  jam session or concert. You don't want to add _any_ latency to the one
>  that speed of light already gives us :-) We routinely run at 64 frames
>  (or 128 if the links are not good). The stock Fedora kernel is just not
>  good enough although I'm sure it is getting better all the time.  
*nod*.  A while ago, I was tempted to add the latency-tracer part of -rt
to Fedora kernels just to see what would show up, but Ingo wasn't really
interested because he felt that we'd get a lot of reports we'd already
fixed in -rt.  

The fundamental changes to spinlocks is probably the real controversial
stuff that's left to go upstream.  How well that goes remains to be seemn
over the coming months.

>  > Right now the guys working on that stuff typically have a
>  > bunch of 'boring' test cases more tailored towards replicating situations
>  > like stock trades and the like.  If we can construct additional use-cases
>  > I'm sure Ingo, Thomas & co would be very interested to hear about them.
>  > Especially if these cases are triggering different latency paths.
>  
>  The apps being worked on at CCRMA (jacktrip) would touch both the
>  network drivers and drivers for pro audio cards. Probably disk as well
>  if the same host is being used to record the performance in Ardour.  
Ok, that's an interesting use-case and in honesty, I don't think it's
too different to the use-cases like the stock trading stuff that people
have been focusing on, so it's understandable why you're reaping
the same rewards.

	Dave

-- 
http://www.codemonkey.org.uk

[Nicholas Manojlovic]

"I'm interested to hear any test cases you guys may have that justify why
you need -rt. "

every.single.time.

without rt, the packages I use are virtually useless. performance sucks.

with rt, a world of good.

it always amazed me that redhat never let Fedora into their 'real-time'
kernel plans. would have been great if fedora was bleeding edge for that
now.



On Thu, Apr 10, 2008 at 5:58 AM, Dave Jones <davej(a)redhat.com&gt; wrote:

>  On Wed, Apr 09, 2008 at 07:42:02PM +0200, Hans de Goede wrote:
>   > I believe this is easily feasible given enough manpower, most ccrma
>  packages
>   > are pretty clean, they just need someone to push them through the
>  review
>   > process, then the biggest hurdle left is ... the rt-kernel.
>   >
>   > Well since I seem to be talking to the right person now, I know you
>  hate this
>   > question, but ... how strongly would you object to having an rt kernel
>  variant
>   > within Fedora?
>
>  Not incredibly keen tbh.  I'd sooner just add -rt to the regular kernel
>  package
>  and suck it up, but that obviously takes us further from our 'upstream
>  first'
>  mantra.
>
>  Ingo & Thomas are getting sizable chunks of it merged upstream, but I
>  don't think
>  we'll be seeing it all merged soon, but then again, F10 is quite a ways
>  off,
>  and with a few more kernel releases, who knows.
>  Depends how objectionable the remaining bits are I guess.
>  Given that so many people are now distributing products based on this
>  work, getting
>  it all in mainline is obviously important, and there's no shortage of
>  manpower
>  helping drive it there.
>
>  All this said, I personally haven't hit any issues with things like MIDI
>  in
>  Fedora where the -rt kernel would have helped me.  Maybe my gear is
>  special,
>  but latency between me hitting a key on a synth and having that note show
>  up in rosegarden, and a sound being created is well below perceivable.
>  I'm interested to hear any test cases you guys may have that justify why
>  you need -rt.  Right now the guys working on that stuff typically have a
>  bunch of 'boring' test cases more tailored towards replicating situations
>  like stock trades and the like.  If we can construct additional use-cases
>  I'm sure Ingo, Thomas & co would be very interested to hear about them.
>  Especially if these cases are triggering different latency paths.
>
>         Dave
>
>  --
>  http://www.codemonkey.org.uk
>
>  _______________________________________________
>  Fedora-music-list mailing list
>  Fedora-music-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-music-list
>

[Fernando Lopez-Lezcano]

On Wed, 2008-04-09 at 21:52 +0200, Hans de Goede wrote:
>  Fernando Lopez-Lezcano wrote:
>  > On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
>  >> ZC Miao wrote:
>  >>> [quote]
>  >>> Ardour 2.4 released
>  >>> Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
>  >>> Well, its over a month later than expected, but Ardour 2.4 is finally
>  >>> here. A respectable list of new features, many small improvements and an
>  >>> important set of bug fixes make up the news for this one. Read more
>  >>> below ...
>  >>> [/quote]
>  >>>
>  >>> So, when will we get it in F8?
>  >>>
>  >> In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering that 
>  >> this not purely a bug fix release I'm not sure if we want to release this as
> an 
>  >> update to F-8. What do others on this list think?
>  > 
>  > I would release it on Fedora 8. It has bug fixes and I think other users
>  > would probably appreciate having the latest. 
>  > 
>  >> You could grab the srpm from rawhide and build it for F-8, and provide us with 
>  >> some feedback on it, that might help.
>  > 
>  > I'll probably try a release in the Planet CCRMA testing repos...
>  
>  Since there seems much demand for this I've just pushed a build of ardour-2.4 
>  to the F-8 updates-testing repo (it will show up there with the next update of 
>  the update repositories). Please give this a thorough testing, then in a couple 
>  of weeks I'll push it to the regular updates repo. 
Thanks...
For my current testing build for Fedora < 9 I use the libraries that
come with Ardour and not the system libraries. I would recommend you do
that too. Last I heard it was a big no-no to replace the internal
libsndfile with the system one, unless things have changed it is going
to break things. Better check with Paul...

-- Fernando

[Fernando Lopez-Lezcano]

On Thu, 2008-04-10 at 02:49 -0700, Fernando Lopez-Lezcano wrote:
>  > Since there seems much demand for this I've just pushed a
> build of ardour-2.4 
>  > to the F-8 updates-testing repo (it will show up there with the next update of 
>  > the update repositories). Please give this a thorough testing, then in a couple 
>  > of weeks I'll push it to the regular updates repo.
>  
>  Thanks...
>  For my current testing build for Fedora < 9 I use the libraries that
>  come with Ardour and not the system libraries. I would recommend you do
>  that too. Last I heard it was a big no-no to replace the internal
>  libsndfile with the system one, unless things have changed it is going
>  to break things. Better check with Paul... 
Hector Centeno (in the Planet CCRMA list) tells me that 2.4.1 is out...
time to upgrade! :-)

-- Fernando

[Hans de Goede]

Fernando Lopez-Lezcano wrote:
>  On Wed, 2008-04-09 at 21:52 +0200, Hans de Goede wrote:
> > Fernando Lopez-Lezcano wrote:
> >> On Mon, 2008-04-07 at 16:03 +0200, Hans de Goede wrote:
> >>> ZC Miao wrote:
> >>>> [quote]
> >>>> Ardour 2.4 released
> >>>> Submitted by paul on Mon, 2008-03-31 21:03. :: Articles
> >>>> Well, its over a month later than expected, but Ardour 2.4 is finally
> >>>> here. A respectable list of new features, many small improvements and an
> >>>> important set of bug fixes make up the news for this one. Read more
> >>>> below ...
> >>>> [/quote]
> >>>>
> >>>> So, when will we get it in F8?
> >>>>
> >>> In F-8, I dunno, it is on its way to rawhide / F-9 beta now. Considering that
>
> >>> this not purely a bug fix release I'm not sure if we want to release this
> as an 
> >>> update to F-8. What do others on this list think?
> >> I would release it on Fedora 8. It has bug fixes and I think other users
> >> would probably appreciate having the latest. 
> >>
> >>> You could grab the srpm from rawhide and build it for F-8, and provide us
> with 
> >>> some feedback on it, that might help.
> >> I'll probably try a release in the Planet CCRMA testing repos...
> > Since there seems much demand for this I've just pushed a build of ardour-2.4 
> > to the F-8 updates-testing repo (it will show up there with the next update of 
> > the update repositories). Please give this a thorough testing, then in a couple 
> > of weeks I'll push it to the regular updates repo.
>  
>  Thanks...
>  For my current testing build for Fedora < 9 I use the libraries that
>  come with Ardour and not the system libraries. I would recommend you do
>  that too. Last I heard it was a big no-no to replace the internal
>  libsndfile with the system one, unless things have changed it is going
>  to break things. Better check with Paul...
>   
We don't use the system libsnd, only those systemlibs which get enabled by 
passing SYSLIB=1 to SConstruct, which does not include libsnd.

Regards,

Hans

[Hans de Goede]

Fernando Lopez-Lezcano wrote:
>  On Thu, 2008-04-10 at 02:49 -0700, Fernando Lopez-Lezcano wrote:
> >> Since there seems much demand for this I've just pushed a build of ardour-2.4
>
> >> to the F-8 updates-testing repo (it will show up there with the next update of 
> >> the update repositories). Please give this a thorough testing, then in a couple 
> >> of weeks I'll push it to the regular updates repo.
> > Thanks...
> > For my current testing build for Fedora < 9 I use the libraries that
> > come with Ardour and not the system libraries. I would recommend you do
> > that too. Last I heard it was a big no-no to replace the internal
> > libsndfile with the system one, unless things have changed it is going
> > to break things. Better check with Paul...
>  
>  Hector Centeno (in the Planet CCRMA list) tells me that 2.4.1 is out...
>  time to upgrade! :-)
>   
2.4.1 is currently building for F-9 and F-8, I will push it to F-8 
updates-testing when its finished building.

Regards,

Hans

[Callum Lerwick]

On Wed, 2008-04-09 at 03:50 -0700, Fernando Lopez-Lezcano wrote:
>  Do we want Fedora/Music to be rock stable? Or do we want a fast
> moving
>  music environment that keeps up to the latest and greatest? The later
>  would seem more "in tune" with Fedora itself and is what I used to do on
>  Planet CCRMA... 
Well going by what started this thread, people seem to want the latest
and greatest. And the latest and greatest is kind of what Fedora is
about. Personally I have used Red Hat/Fedora since RH5.2 because it
always seemed to be able to ride the cutting edge without straying in to
the ragged bleeding edge. Perhaps we've stumbled over that line since
the RHL days, but I don't think I can make an objective judgment
anymore. I'm too deep in it now. :)

Also, music production is still a fairly new area of open source
development, an area that's still in rapid development. With some apps I
don't think there is much stability to be found by standing still. But
we should be a little bit careful. Perhaps we ought to make better use
of "updates-testing". Get updates out quick into testing, and get people
to test them before pushing them to the main repo. I wish it was easier
to just test certain packages without opening up your system to the
entirety of updates-testing...

And on a tangent, the main reason I got in to this Fedora music project
is due to CCRMA being too slow... as far as keeping up with Fedora
itself. :) A while back I was really wanting stuff from CCRMA, but at
the time CCRMA was still stuck on FC3/4 when FC5/6 was current. (Or
something like that.) That may have changed since then, hopefully
because of our work :), but at any rate, we should keep in mind one of
the big advantages of moving stuff into Fedora itself is you get the
full support of the entire Fedora project when it comes to major
distro-wide changes. The upgrade to gcc 4.3 for example. Automated
rebuilds are used to detect breakage early on, and fixed before release
so that everything is ready to go on release day. No more lagging
behind. The farther CCRMA diverges from Fedora, the harder it is to
rebase it on a new Fedora release.

(Which, as davej pointed out, is the same reasoning behind why we don't
like carrying kernel patches...)