Harald Hoyer wrote:

Harald Hoyer wrote:

Anyone interested in an audio SIG?

We could create a jacklab like spin ( http://jacklab.org/ ) with jackd
as the main audio daemon.




Add yourself to
https://fedoraproject.org/wiki/SIGs/Audio
if you are interested



ok, there is already such a SIG called AudioCreation


http://fedoraproject.org/wiki/SIGs/AudioCreation

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

John Poelstra wrote:
Unless it is really ready for FESCo acceptance, please put it in
Category:ProposedFeature The purpose of this category is to collect
ideas like this and not be tied to a particular release until they are
ready.




Hmm, how or where does FESCo fit in the picture between proposal, Spin
SIG, Board, Release Engineering and QA?


Does the Spin also need to be approved by FESCo before inclusion to a
release?


Kind regards,

Jeroen van Meeuwen
-kanarip

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Fri, 2008-07-11 at 14:01 +0200, Jeroen van Meeuwen wrote:
>
> Hmm, how or where does FESCo fit in the picture between proposal, Spin
> SIG, Board, Release Engineering and QA?
>
> Does the Spin also need to be approved by FESCo before inclusion to a
> release?

I thought we had come to the conclusion that each spin was a feature and
thus would go through the normal feature process, which means getting
approval from FESCo as a feature. Having the spin already approved by
the SIG/Releng/Board means that FESCo can avoid pondering the spin
itself and concentrate more on the other parts of the feature process.

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating wrote:

On Fri, 2008-07-11 at 14:01 +0200, Jeroen van Meeuwen wrote:
Hmm, how or where does FESCo fit in the picture between proposal, Spin
SIG, Board, Release Engineering and QA?


Does the Spin also need to be approved by FESCo before inclusion to a
release?


I thought we had come to the conclusion that each spin was a feature and
thus would go through the normal feature process, which means getting
approval from FESCo as a feature. Having the spin already approved by
the SIG/Releng/Board means that FESCo can avoid pondering the spin
itself and concentrate more on the other parts of the feature process.



Right, that's what I wanted to verify ... ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Thu, 2008-07-10 at 17:40 +0200, Harald Hoyer wrote:
> Michal Schmidt wrote:
> > On Thu, 10 Jul 2008 13:40:26 +0200
> > Harald Hoyer <harald@redhat.com> wrote:
> >
> >> Anyone interested in an audio SIG?
> >>
> >> We could create a jacklab like spin ( http://jacklab.org/ ) with
> >> jackd as the main audio daemon.

(or Ubuntu Studio, the Gentoo pro audio overlay, 64Studio, etc, etc,
pretty much all big distros already have it)

> > Would the absence of a real-time kernel variant in Fedora be a problem
> > for such a spin?

Yes.

> > Fedora kernel only has voluntary preemption enabled.
> > All the audio-specialized distributions I've heard about ship with an
> > RT-patched kernel.
> >
>
> Absence is no "problem" on a modern desktop (my desktop :-) ), though a
> real-time kernel would definitely improve the latency for slower systems.

Nope. It is a problem.

A stock Fedora kernel can have latency problems if you use jackd with 64
or 128 frames per period[*]. One hiccup is enough to ruin a performance
or a recording session. That is why other audio oriented distros use a
realtime patched kernel (as does Planet CCRMA, which I maintain).

You could define your "target user base" to not need that level of
performance, and then sidestep the issue. But then you can't compare a
hypothetical Fedora JackStudio or whatever distro with other audio
oriented distros that have a realtime patched kernel.

> Maybe we could "maintain" a kernel-rt package or persuade our RHEL5 kernel team
> to provide a rt-kernel (with the benefit of more QA ).

I've been "maintaining" one for Planet CCRMA since 2001. It is not fun
(well, it used to be, many years ago) and it is a worthy task for
Sisyphus. I made some noise in the fedora audio list a while back about
this, but there's no manpower for doing a realtime kernel on Fedora.
RedHat itself does have a realtime patched MRG kernel for RHEL.

-- Fernando
[*] depends on your particular hardware configuration, sound card model,
interrupt sharing, usage patterns, and the phase of the moon for all I
know :-)


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list