I'm pretty new to Logic and I am a little surprised I am finding a Core Audio error or rather inability to process the audio in a portion of a song. No more than about 12 tracks, all VI's from within Logic, a region just like 32 bars early plays fine, no new parts, no additional audio just a single audio drum loop...just an error in one predicable spot. I've gone through all the tracks and checked everything for complicated automation changes...thought I had it when I flattened out a cutoff automation change in a region...but Core Audio just doesn't process reliably in that area at odd times. Dual G4 450/ 1GB of RAM/ and plenty of free disk space if that is an issue. Should I: 1. Restart 2. Run the Terminal and fetch back the unused RAM with the <sudo /etc/weekly> script. 3. Or consider another audio card or audio interface. If the answer is "3." I know this question comes up on this forum with a relentless frequency, in part because of new models that are being released, in part as a general recommendation for such a product. Perhaps someone can point out the particulars in considerations for buying an audio card for someone who will have limited need for external audio routing and wishing to simply boost the internal "oompf" of the Mac audio processing. Any other consideration as to why this would occur are also welcome. The archives are sometimes hard to navigate, I'll apologize for this now. John Lee Logic Audio 6.3.1

On Apr 3, 2004, at 10:15 PM, J. Arthur Lee wrote: > Should I: > 1. Restart > 2. Run the Terminal and fetch back the unused RAM with the <sudo > /etc/weekly> script. > 3. Or consider another audio card or audio interface. Argh, lately I am seeing this "should I run /etc/weekly script" thing come up on audio forums as a "way to reclaim RAM." This method is about equivalent in validity to your typical wife's tale. I guess it's expected, considering many people new to OSX don't realize how UNIX-like memory management works, and superstition regarding the presumed function of a value abounds. If you've ever inspected the /etc/weekly script, you'll see it does basically two things, none of which directly address reclaiming "unused RAM" Thing 1 is that it runs a programs which updates the locate database, a database of all files on the system, so that if you were at the Terminal prompt, you would type 'locate <file>" and it would show you the location of it. Thing 2 is that it rotates the log files found in /var/log of your system and restarts the log daemon (process) which creates them. One of the system-level results of this action are what most people perceive as RAM being "freed" up. What /is/ being freed up are parts of the file system cache. The file cache is a buffer that the OS keeps in memory of open or recently used file data and file system metadata. Its function is simply to reduce any future need of the OS having to go to disk for that data... RAM is much faster so it maintains the cache there. Makes sense, yes? As file data changes, obviously parts of that cache become invalid and are "faulted" and returned to the unused memory pool. That's why the rotation of the /var/log files has such an impact. These files can grow in size quite a bit depending on what you run. When you run /etc/weekly, these files are closed and rotated... which causes the OS to invalidate any file system cache about them. This in turn is what you see as "RAM being freed up." But isn't it a good thing? More RAM for my apps instead of those files I have no use for? Well, you're missing a big part of the management of this file system cache. The OS will shrink or grow this cache depending on the needs of what is running on the system. If you start Logic up and it requires more RAM than is available, the file system cache is reduced and the OS gives it to Logic. It's as simple as that. It's part of the robust protected memory management provided in UNIXes such as OSX. /dale