Hello

According to my exp. through the years of performing live mixing/sound processing with computer and FF800 interface 96 samples @ 48 kHz is the best choice between latency and performance. If you do not have disk activity in your DAW (no recording or playback) you can go to the lowest 48 without dropouts (with Core i7 you described). With disk I/O and 64 samples you will have some dropouts (1-2 in one hour) I'm pretty shure. Maybe not with SSD HD but with classic one dropouts will be present. With 96 samples dropouts will disappear (they do in my case).

regards

THanks for sharing your experience!

I personally use 48kHz for movies only though. And I cannot really use 96 samples. For a particular reason that I can explain if you want but I'm afraid it's not very interesting here, I get way better performance when using latencies that are a power of 2. Then it's either 64 or 128. If I work at 96 samples latency, it uses way more CPU than 64.

Best regards
Happy new year
-j

No problem for working with 96 smp buffers fortunately But on some softwares like Max/MSP, it takes more CPU than 64 samples. Here is the explanation.

When programming a realtime audio software, you use a software DSP buffer that can have a different size compared to the hardware DSP buffer; in any case the hardware buffer size must be a multiple of the software buffer size.

For a given latency, you get the lowest CPU load if the software buffer has the same size as the hardware buffer. For example, if the hardware buffer is set to 64 samples, using a 64-sample software buffer will take less CPU than a 32-sample or a 8-sample software buffer.

The actual latency is given by the hardware buffer size, not by the software buffer size.
The only reason for using smaller software buffers is when requiring very short delay lines with a feedback loop: in this case, the delay time cannot be shorter than the time that corresponds to the size of the software buffer. If you need very short delays, you can still use a very small software buffer size for the delay computation only and a big software buffer size for the remaining of the program (this is even possible in Max/MSP and Pure Data).

Let's consider you want to use the biggest possible software buffer size for a given hardware buffer size. The problem with Max/MSP is that it only supports software buffer sizes that are a power of 2 (while, if I remember correctly, Pure Data can use any size -- and of course if you use C, C++ or C# you can use any size as well).
With Max/MSP, when using a hardware buffer of 64 samples you can also set the software buffer size to 64 (as 2^6 = 64), which is optimal in terms of latency vs CPU load ratio. But if the hardware buffer is set to 96 samples, the biggest possible software size is 32 samples (as 3 * 2^5 = 96). A software buffer size of 32 samples uses way more CPU than 64 samples (at least on my computer). Therefore, when using Max/MSP, if I choose a hardware buffer size of 64 samples instead of 96, I get a better latency, less CPU load and a better stability. Of course, if it was possible to use a 96-sample software buffer size in Max, it would be different!

For me this means that:

1. When using Max/MSP you should have an audio interface that supports power-of-2 hardware buffer sizes (for example RME and M-Audio can do this, but not Edirol nor Presonus)

2. The Max/MSP audio engine may need to be reworked

I don't use Max only, but because of this Max problem I choosed to use a latency of 64 samples when working in live. I would not want to change the latency each time I run a particular software
I admit I could not find any equivalent to Max besides classic programmation languages (C, etc). But currently I don't know how to program audio softwares with these languages. I need to study things like audio file access, standard DSP frameworks like VST, advanced multithreading, etc.

Best,
-j