My New Build

[John Ludlow]

No. One more.

Today I discovered something that I'll bet many of you already know: if you left click on the "Load" text readout a new window temporarily pops up that lets you know how many slipped (not dropped) buffers have occurred since SAC last went live. I am not the sort of user who reads the manual cover to cover. Rather, when I don't already know how to do something - I search the manual looking for it. I searched for 'dropped' buffers and didn't find anything.

I did all my previous tests with only a subjective idea of whether there were dropped buffers. Just on a whim today I searched the SAC manual for 'slipped' buffers and now I know how to measure them. This is a very useful feature.

As a result, I felt that I needed to do at least the last 119 channel/track test again. I did and noted that I had over 300 slipped buffers during an hour recording. This was a good enough reason to try to improve. I tried nearly every permutation of the processor limiting and etc. options (but not combinations of individual failures...). Ultimately, the one that worked the best for me was to "Force Single CPU". With that set I repeated the previous 119 track test, and it lowered the slipped buffers to 85 'corrected' buffers.

I'm not really sure how missing data can be 'corrected' - or what the difference between one that has been corrected and one that hasn't is. It seems to me that the data is either there or not - but clearly it is more complicated than that. That's a point of confusion for me. Maybe it means that a blank sample has been inserted in place of the missing one so that the stream remains in synch at least. So, in that case data is either 'there', 'not there', or null and SAC has repaired the stream such that the sample is not there rather than null.

But, at any rate, I believe that means that there was less than 1 slipped buffer per track per hour. I'm disappointed that it's not perfect. But - on the other hand, it is a lot of simultaneous channels too (119 x 3 x 2). Plus, I've listened, but I haven't actually heard a tick - which is what is most important to me. It could be that the distribution is such that they can't be heard. But, for that, I haven't listened to every channel either. Maybe a hideous crackle is hiding somewhere in one of them - or maybe there was one in one of the monitor mix channels - which were all headed to void. It puts a bit of a wet blanket on my capacity results. Ultimately, I'm still pleased - but most especially because I will never approach 119 channels in my own recording. Otherwise maybe I would overclock the processor and switch out the stock cpu cooler for a water cooler - or just get a faster processor.

I'm realizing now that I probably need to back off to one 64-sample buffer and try that one more time. Maybe that will give me the perfect result I'm hoping for. And maybe I need to figure out how many perfect tracks are possible for me at 1-32 as well.

I'm really looking forward to doing something other than capacity stress tests at this point. But, it would be a shame not to nail it down. And not much time left before Monday when the monitors get here. After that I need to shift focus.