On 9/4/01 9:57 PM, "Joseph A. Sarlo" jsarlo@mambo.peabody.jhu.edu wrote:
Well, you should definately run PD with -rt. If you're calling GrIPD with an "open" message, the GrIPD GUI will run with priority 0 (SCHED_OTHER) schedualing (as opposed to PD's 96), so that helps a lot. Are you getting DIO errors? I've found in some of the later versions of PD that I sometimes get a crackling in audio with no DIO errors and low CPU usage, and I'm not sure why.
no DIO errors.
Can you run other reasonably low utilization apps simultaneously with your patch without problem or is it just GrIPD?
Yup. Gimp causes far less interruptions. Every time I move a mouse within the bounds of GrIPD's window I get lots of clackling. And I mean a lot. Kinda like granular synthesis :)
SOCKETTIMERTIME = 5
poll_send/receive doesn't change anything but SOCKETTIMERTIME does but not a lot. And this really happen only when I read from arrays using tabread4~. Any other patch works fine.
Also, I'm not sure, but using a non-bitmap GTK theme might help. I've also found, from purely a voodoo standpoint, that opening the GrIPD GUI before I start audio seems to help.
Yeah, non-bitmap GTK. And I always opened GUI before audio....
However, from the little monitoring I did, I think my main problem is RAM. I don't know how related that is but I've noticed that every time I move the mouse around X(server) gets all the way up in 'top'. Also, top reports that X size is 119M which is almost twice the size of my RAM. Which explains %MEM = 194. Assuming that arrays are sitting in the memory as well I'm led to think that, indeed, RAM is at cause here. I think I will give up GrIPD until I get/borrow some RAM and will test it then again. For now, I almost finished my GUI with iemlib :)
Thanks anyways.
./MiS