Hello, All: Pleased to see activity on the list. I work with a small group on Open Studios, a nonprofit relying on both Fedora and CCRMA to provide multimedia capability for users. Our target audience lies mainly with independent musicians, inner-city neighborhoods, nonprofits, etc., that are looking for multimedia capability, but generally lack money to purchase proprietary products.
Greg mentions that one topic of high interest is discussing how Fedora and CCRMA can work together to create multimedia capability in a way that benefits everyone involved. My first question to the list, and Fernando, is, what applications are on the short list (if there is one at this point) for moving to Fedora Extras? Also, what is the present recommendation for users that have installed Fedora and CCRMA to maintain both up-to-date? Tom
On Mon, 2006-04-17 at 17:22 -0500, Tom Poe wrote:
Hello, All: Pleased to see activity on the list. I work with a small group on Open Studios, a nonprofit relying on both Fedora and CCRMA to provide multimedia capability for users. Our target audience lies mainly with independent musicians, inner-city neighborhoods, nonprofits, etc., that are looking for multimedia capability, but generally lack money to purchase proprietary products.
Greg mentions that one topic of high interest is discussing how Fedora and CCRMA can work together to create multimedia capability in a way that benefits everyone involved. My first question to the list, and Fernando, is, what applications are on the short list (if there is one at this point) for moving to Fedora Extras?
The most important "enabler" application is the Jack Audio Connection Kit sound server. Pretty much everything of value for audio and music is a client to Jack, so without Jack we are stuck.
Adding Jack to extras brings up a couple of points:
- a proper kernel, whatever that is. The normal Fedora Core is probably fine as long as you do not need very low latencies (ie: just a guess, > 15 milliseconds).
- instructions on how to get access to realtime priority and memory locking as a normal non-root user (involves editing /etc/security/limits.con).
Without the first (a good kernel) users that lower latencies to smaller numbers will get xruns from alsa. Without the second Jack is not very usable, you really want realtime priority - Planet CCRMA comes with a patched pam that has that enabled by default.
Also, what is the present recommendation for users that have installed Fedora and CCRMA to maintain both up-to-date?
Which FC? FC4 I guess? Hmmm, there may be some overlaps with Extras that are not completely compatible, I have not checked in a while. Have you had problems?
-- Fernando
On Mon, 2006-04-17 at 17:21 -0700, Fernando Lopez-Lezcano wrote:
On Mon, 2006-04-17 at 17:22 -0500, Tom Poe wrote:
Hello, All: Pleased to see activity on the list. I work with a small group on Open Studios, a nonprofit relying on both Fedora and CCRMA to provide multimedia capability for users. Our target audience lies mainly with independent musicians, inner-city neighborhoods, nonprofits, etc., that are looking for multimedia capability, but generally lack money to purchase proprietary products.
Greg mentions that one topic of high interest is discussing how Fedora and CCRMA can work together to create multimedia capability in a way that benefits everyone involved. My first question to the list, and Fernando, is, what applications are on the short list (if there is one at this point) for moving to Fedora Extras?
The most important "enabler" application is the Jack Audio Connection Kit sound server. Pretty much everything of value for audio and music is a client to Jack, so without Jack we are stuck.
[MUNCH]
I'm attaching my current unedited (ie: not edible by Fedora Extras :-) spec file for Jack... This is for CVS of the clock_fix branch, which fixes problems with low level timing on dual core Athlon processors (you also need a recent kernel that does not select the TSC for internal timing on those processors to make everything work correctly)
Ah, I forgot - if you are using a proper "preempt" kernel then you also want Rui Nuno Capella's rtirq script (also part of Planet CCRMA) which optimizes the priority of irq processes to favor audio i/o - that's mentioned in the jack spec file, that's why I remembered.
-- Fernando
On Mon, Apr 17, 2006 at 05:39:06PM -0700, Fernando Lopez-Lezcano wrote:
I'm attaching my current unedited (ie: not edible by Fedora Extras :-) spec file for Jack... This is for CVS of the clock_fix branch, which fixes problems with low level timing on dual core Athlon processors (you also need a recent kernel that does not select the TSC for internal timing on those processors to make everything work correctly)
Ah, I forgot - if you are using a proper "preempt" kernel then you also want Rui Nuno Capella's rtirq script (also part of Planet CCRMA) which optimizes the priority of irq processes to favor audio i/o - that's mentioned in the jack spec file, that's why I remembered.
Seems to build for me using mock to build it into a fc-devel build root. I don't think I build the right cvs branch though, since I just used the "jack-get-cvs" to build a tarball from cvs and built that with the spec provided. So I just built HEAD so far.
What are you using for your build system?
Adrian
On Tue, 2006-04-18 at 13:19 -0400, Adrian Likins wrote:
On Mon, Apr 17, 2006 at 05:39:06PM -0700, Fernando Lopez-Lezcano wrote:
I'm attaching my current unedited (ie: not edible by Fedora Extras :-) spec file for Jack... This is for CVS of the clock_fix branch, which fixes problems with low level timing on dual core Athlon processors (you also need a recent kernel that does not select the TSC for internal timing on those processors to make everything work correctly)
Ah, I forgot - if you are using a proper "preempt" kernel then you also want Rui Nuno Capella's rtirq script (also part of Planet CCRMA) which optimizes the priority of irq processes to favor audio i/o - that's mentioned in the jack spec file, that's why I remembered.
Seems to build for me using mock to build it into a fc-devel build root.
No changes? That's a good start...
I don't think I build the right cvs branch though, since I just used the "jack-get-cvs" to build a tarball from cvs and built that with the spec provided. So I just built HEAD so far.
The one I'm building is this:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jackit login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/jackit co -rclockfix jack
The latest jack-get-cvs has this built in but the SRPM was not out for that particular one because I was only doing internal testing, but I just made it available: http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/jack-audio-conn...
This is not the latest jack but it is the latest with the clock fixes. Jack used to use the TSC directly for internal high resolution timing but that is impossible in the latest dual core Athlons where the TSC's from the two processors can and do drift apart over time.
What are you using for your build system?
I'm using mach - still using apt for the build environment, I have to switch to yum, the build root is in RAM (for speed) unpacked for each build from a tar.gz snapshot. I have a set of scripts for handling builds, snapshots, etc, they define "fcx" for each distribution so that conditional things in the spec files work fine - I use one spec file to build on different versions of rh/fc. They also define a release postfix that becomes part of the release field (currently "rhfcx.ccrma") for id'ing each rpm. I think the "bare" environment I use is too sparsely populated so there will be more build dependencies in the spec file than are probably needed for the redhat build system (I prefer to include as few default packages as possible but that's just me).
-- Fernando
-
Adrian Likins -
Fernando Lopez-Lezcano -
Tom Poe