[PlanetCCRMA] Installing on CentOS

[don.estabrook at gmail.com]

On Sun, 2008-11-02 at 15:18 -0800, Ken Ellinwood wrote:
> Here are the steps I took:
> 
> 1) rpm -i http://ccrma.stanford.edu/planetccrma/mirror/centos/linux/planetccrma/5/i386/planetccrma-repo-1.1-1.el5.ccrma.noarch.rpm
> 
> 2) rpm --import http://ccrma.stanford.edu/planetccrma/RPM-GPG-KEY.planetccrma.txt
> 
> 3) rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
> 
> 4) yum install planetccrma-core
> 
> Step 3 installs the EPEL repository which is required by some critical
> CCRMA components to resolve dependencies.  After getting the core
> installed, I individually installed apps that I wanted with separate
> 'yum install' commands.  To install all apps in one go I've heard the
> following will work:
> 
> 5) wget http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/8/i386/planetccrma-apps-2007.11.22-1.fc8.ccrma.i386.rpm
> 
> 6) yum install planetccrma-apps-2007.11.22-1.fc8.ccrma.i386.rpm
> 
> Hope that helps,
> 
> Ken

It definitely helped, thanks!  I can confirm that step 3 was required,
as you said, and steps 5 and 6 also worked.

Now that you've had some time, has your CCRMA on CentOS installation
been working well?

I just did a CentOS install this past week-end, and while it seemed OK
at first, I've already had two hard lock-ups in that time.  One was
while sitting idle overnight (but jackd may have been running, not
sure), and the other was while recording two channels in Ardour [1].
There was nothing useful in /var/log/messages after rebooting either
time.

This is on a machine that had been running F7 + CCRMA until a recent
hard disk failure.  The performance on this box has never been
impressive [2], but at least crashes were rare.  Here are a few hardware
details (from memory and a couple scribbled notes; I'm not near it at
the moment):

    mainboard:  Biostar U8668 Grand (VIA P4M266A / VT8235)
    CPU:        2-GHz Celeron (complete with its tiny L2 cache)
    RAM:        768 MiB DDR2
    audio I/O:  M-Audio Delta 66 in 1st PCI slot
                (no other PCI cards currently installed)

I'm using the CCRMA RT kernel that comes from the above procedure,
2.6.24<something>, IIRC...  It looked very similar to or same as the
latest for F8, which is running fine on another box.  I'm also using
xfce and relatively few other GUI apps in hopes of reducing memory
footprint and CPU load.  As far as I can tell it isn't swapping.  I
should probably mention that the X session is running under VNC (Xvnc)
rather than on the console (X), so there should be no issues with video
drivers and such, but there is some steady network traffic when a
viewer is connected.

jackd also crashed once during recording of only one channel, again on
Ardour.  (We were in a hurry at the time, so I don't have any jack
output to report, sorry.)  I'm planning to take Fernando's advice from
other threads and switch to the new jackmp, but as I recall, I didn't
see that in the repos for CentOS (doing "yum list 'jack*'").

We hope to upgrade the HW sometime soon, but I wanted to double-check
that the CentOS installation _should_ be solid, before spending any more
time on it.

Thanks much,
Don

[1] : That's Ardour 2.4.1 : I haven't found anything more recent in the
      repos, and some of the build dependencies don't seem to be
      available either.  I haven't had time to chase down all the
      sources.  Yeah, I know - CentOS is the stable place, not for
      bleeding-edge stuff.., but from what I've seen (and read on the
      Ardour maillist), old versions don't necessarily equate to
      stability, as lots of bugs are being fixed in newer releases.  I
      guess it all depends on one's definition of stability...

[2] : For example, even with F7, we could not get latencies under about
      60 ms without getting xruns, and even then we would occasionally
      get a click (which looked to be dropped sample(s)) in audio
      recorded by Ardour, even though jack had not reported any xruns.