Now I've got a new PreSonus FireStudio Mobile firewire audio interface and have upgraded to 4gb of ram. Pianoteq works fine now without crackles or latency (I did manage to coax temporary crackles out of it before upgrading the ram).

Before the upgrades I tried resetting pram, which didn't work.

My kernel is 32-bit.

My iMac is a mid 2007 model, Model Identifier: iMac7,1

It's a good thing you can't buy an Edirol FA-66 anymore; I can't recommend them

Thanks for all the good ideas, guys!

check the sample rates (internal core and interface one must match)
check wether your kernel runs in 64 or 32 bit
check your firewire cable

to perform the second check do the following (considering I'm translating menu from italian a little interpretation is necessary here ): open 'about this mac' from apple menu and 'more info'; you should be in system profiler now. Click on the third main menu 'Software' and check wether the line 'extensions and kernel 64 bit' says yes or not.
In the rare case of 'yes' restart your mac and keep 3 and 2 keys pressed during reboot; this will force your kernel to 32 bit (check if it worked in system profiler). Now test your interface.

Other than that I think your only possibility is to change the interface or ask to edirol that basically means change your interface..

The Built-in Output appears to work flawlessly. In fact it's quite astonishing how much I can push my system, how much stuff I can have going at once, without causing any extra latency (although I can make it crackle just a little bit as CPU usage goes above about 80%).

I ran Pianoteq in 32-bit mode (checking the box in the Info window for the application in the Finder) and that had no effect.

There don't appear to be any Mac drivers for the Edirol FA-66, just for various versions of Windows, etc.

I'm still trying different things, and will post the results.

RAM is allocated in pages, so there's no way to lose memory due to fragmentation. Also, access times are the same, regardless of how contiguous the pages are, so fragmentation is really not an issue. Still, rebooting will clear out any extra memory that hasn't been properly deallocated, so it's still good advice if the system has been running for a while.

Thank you for clarification Jerry

good luck

cheers
Hans

"be sure you restart your system (not just put to sleep and wake it up; even if you close applications ram becomes more and more fragmented and new apps can't allocate all the free space)"

Not that it matters much to the discussion, but this is incorrect. RAM is allocated in pages, so there's no way to lose memory due to fragmentation. Also, access times are the same, regardless of how contiguous the pages are, so fragmentation is really not an issue. Still, rebooting will clear out any extra memory that hasn't been properly deallocated, so it's still good advice if the system has been running for a while.

Potential 64bit vs 32bit issues is a good point that I didn't think of. It will be interesting if that ends up being a contributing factor, since I'm sure many Mac users have very similar setups as Halleys5th.

Hope you can narrow down the problem. Let us know!

Try these things:

-be sure you restart your system (not just put to sleep and wake it up; even if you close applications ram becomes more and more fragmented and new apps can't allocate all the free space)

-try PTQ with internal mac driver and not through your audio interface: it could be that your kernel runs 64bit but your interface driver is still 32bit

-trash PTQ preferences

-launch PTQ in 32bit mode

-reset pram and check your disk integrity and permissions

-let us know if anything change

Increasing the buffer size to 512 samples (10.7ms) has no effect (but I'd rather restart the program all the time than live with that amount of latency).

I'm now running the up-to-date version, 3.6.8, and it has the same problem.

Turning off multicore rendering seems to decrease performance, otherwise it has no effect.

When it's having the problem, changing the audio buffer size (even back to the setting it was just on) fixes the latency issue, but not the crackling.

Whatever the problem is, it's something that restarting the program fixes. I can reliably cause the problem by opening iTunes, Google Earth, Safari and Firefox, and then closing all three. Pianoteq barely functions at all when the programs are opening, then has horrible latency while they're open, and still has horrible latency after all three programs are closed. If I restart Pianoteq it works fine, and even if I restart it while everything is still open it cures the latency problem, but not the crackling.

Does anyone else ever need to restart Pianoteq?

The sample rate is a little higher than the standard 44100 I use, but I'm not an audio engineer, so I don't know how that could affect anything.

Maybe try turning off the multicore rendering for a while to see if that changes anything. I've had problems in the past with it causing problems.

Perhaps this occurrence might shed some light on the issue: I started playing for the first time this morning, with plenty of system resources available, and there was no discernable latency but there were some crackles, then I played a lot of notes with sustain and there was silence for a moment (CPU overload detection kicking in?), then the latency had gone way up to about 500ms for every keystroke and stayed that way until I restarted the program.

In addition to restarting the program, it appears that I can also fix the problem by making a change to the *internal sample rate* (and then putting it back to what it was on).

Here's my Pianoteq settings:

DEVICES:
Sample rate: 48000 Hz
Audio buffer size: 256 samples (5.3ms)

PERF:
CPU identification: Core 2 Duo 2.4 GHz
Performance Index: 39
Multicore rendering: (checked)
CPU Overload detection: (checked)
Internal sample rate: 48000
Host sample rate: 48000
Buffer size: 256 samples
Maximum polyphony: 256 (I've usually been using Auto, pessimistic)

ABOUT:
Name: Pianoteq, Standalone, 64-bit
Version: 3.6.6

Thanks for the help!