rbowser
The drawback to having your buffer super large is that there will be a longer and longer gap between when you hit Play and when playback is possible...
So basically, even though my CPU is 2.9GHz dual core, it's still the bottleneck in my system - I'm reading 1.2G RAM in Task Manager and Sonar has "committed" 1.6G out of my 2Gigs so it's not the RAM.
Ok, so I got really scientific and worked out that with a buffer of 1024 smpls, it will be less than a 48th of a second between pressing play and hearing the music - working at 48K. So I could turm the buffer up to 4'800 smpls and still only have to wait a tenth of a second. I mean. life is short n' all that, but I think even at my age......
Could this be an indication of a sensible way to do a master recording or mixdown to ensure absolutely no pops and crackles from the CPU?
That's given me some new and tangible stuff to play with - for example; direct monitoring is a good thing.
Thanks RB, very useful.
EDIT: ....I knew that bunsen burner and white coat would come in useful one day: Ok I just pushed the
buffer out to it's max of 4096 smpls and my rig popped and pharted like a good un' - this must mean that the buffer is not big enough to accommodate that many samples. I made a
phew tests and 1280 seems to be the max.
So I grabbed my Tommie Tippie - a calculator that's about the same size as a small laptop - and divided 48'000 by 1280 and it came up with 37.5: Now I know that 4'800 is a tenth of a second, so 37.5 might be milliseconds? I see now that the sound has an input and output latency - a
round trip as it's called - so that might be something less than 140 ms. I think I can wait that long. :)
post edited by edjay - 2011/05/15 08:05:29