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@xxxxxxxxxxxxxxxxxxx:/cvsroot/jackit login cvs -z3 -d:pserver:anonymous@xxxxxxxxxxxxxxxxxxx:/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-connection-kit-0.101.0-0.2.cvs.src.rpm 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
