[PlanetCCRMA] xruns

[Joseph Dell'Orfano]

Thanks for the reply. I don't think I had freeverb open at the time. I
just finished a 5-6 hour session without any difficulty. The only time
my CPU load peaked out was during export to wav. 

I don't know what a denormal is, but it sounds bad. Is there a solution,
assuming that this may have been partly to blame for the behavior I
occasionally experience?

I take it then that there is nothing intrinsically wrong with running
gnome on a standard fc1 distro, right? I assume my machine doesn't look
too different from a bunch of yours!

Thanks again for the response. I am amazed at the energy and time you
put into this. 

-Joe D


On Fri, 2005-01-28 at 13:27, Fernando Lopez-Lezcano wrote:
> On Thu, 2005-01-27 at 21:37, Joseph Dell'Orfano wrote:
> > I am running fc1 with PlanetCCRMA packages, all up to date, on an athlon
> > based system with 1G RAM, low latency, tuned HD, etc. I generally record
> > with good results on Ardour, with Jack set to a 1024 buffer, with h/w
> > monitoring on my delta 1010LT card. However, I sometimes find that xruns
> > start after a while. It almost seems like I'm experiencing a memory leak
> > somewhere. After some non-specific time, xruns start happening and the
> > whole system slows down. ps -aux doesn't show anything unusual going on.
> > 
> > My question is, since I have a rather standard system, has anybody else
> > observed this behavior specifically with fedora core 1? I understand
> > that many linux audio users are running fluxbox or some other low
> > overhead GUI other than Gnome or KDE in order to avoid performance
> > issues. Have other planet users had to do this? Any ideas on hunting
> > down a memory leak?
> 
> Check what's happening with cpu load (does it go up when you start
> experiencing xruns?). This could be a denormal problem, some ladspa
> plugins (most notably freeverb) have issues with denormals (very very
> small numbers that are not zero - the cpu treats them differently and
> that is very expensive in cpu power). 
> 
> -- Fernando
> 
>