Buffer question

[AudioAstronomer]

So, very simple I think. What are the benefits if any between the two scenario's.

1x512
2x256
4x128
8x64

What is the general concensus and the technical benefit of each? They all arive at the same overall usable mixing latency (10.6) at 48khz.

[Jesse Skeens]

From reading the manual it seems like its all what your soundcard likes best. I'm not sure there is a wrong or right that can be said for one way or the other. Just use the one that gives you the lowest latency with no side effects.

Out of curiosity why do you record at 48k? Do you then capture from the analog domain back in at 44.1k?

Also anyone know if mastering houses accept 96k files? I'm thinking of doing my final bounce at 96k (from my Otari)

Jesse

[Yura]

If you'll measure the phisical latency for each of 4 those setups, you'll see it is different for each and not 10.6 ms.
if you'll do the corresponding tests for each setups with different priority of HD load and Proc load, you probably will see the concrete results for each of them.

[AudioAstronomer]

If you'll measure the phisical latency for each of 4 those setups, you'll see it is different for each and not 10.6 ms.
if you'll do the corresponding tests for each setups with different priority of HD load and Proc load, you probably will see the concrete results for each of them.

Why is it different for each? am I mising something?

[Bob L]

Robert,

Yes... the number of total samples as in 2x512 = 1024 and 4x256=1024 is the total latency inside SAWStudio as far as grabbing controls and preloading data buffers...

The actual buffer size setting is what the soundcard sends and recives its data packets in... therefore in the above examples, the 256 buffer size would actually arrive at less monitor foldback latency due to the smaller buffer size.

SAWStudio preloads data according to the limits set in those settings... there can be a big performance difference between 4x256 and 1x1024 due to the fact that SAWStudio will not preload ahead more than 1 buffer in the latter case... this means that it scans and processes 1 buffer of MT data... then waits till the soundcard sends it out before starting to assemble the next buffer... this can result in a glitched buffer or machine too slow message if at some point something takes over Windows and interupts SAWStudio's threads before the next buffer is assembled in time for the soundcard's request...

Having more buffers at a smaller size may give overall better performance on dense sessions because the instant SAWStudio finishes processing the MT and assembling a buffer, it can continue directly on to assembling the next buffer ahead of time and so forth up to the number of preload buffers set... then it waits... this caches data while still maintaining realtime latency... but it is not riding on the edge all the time just in case Windows interrupts my threads, because there are already buffers prepared when the soundcard requests the next one.

Hope that is not getting too technical... but you asked. :)

Bob L

[AudioAstronomer]

I always want technical :) The more there is, the happier I am. I spent the majority of my non-musical life programming chess software that plays over a network on linux (it is now one of the worlds top chess softwares). Working with some of those algorithms and formula's at such a relatively young age I feel pretty confident I can understand anything if i put my mind to it. And Im the type who likes to take EVERYTHING apart and try and put it back together.... if you cant tell :) So hit me with all you got!

[Bob L]

Good... then hopefully that answer gave you some new things to experiment with... it just keeps on going and going and going...

Like our little bunny friend. :)

Bob L

[AudioAstronomer]

I am not too versed in windows threading. what are some things that would cause windows to spawn a new thread or otherwise interupt those in sawstudio?

[Jesse Skeens]

When it comes to playing VSTi's does the total latency (ie: 2 X 512=1024) or single buffer (512) end up being the perceived delay?

[AudioAstronomer]

When it comes to playing VSTi's does the total latency (ie: 2 X 512=1024) or single buffer (512) end up being the perceived delay?

That's a good question. Likewise for live monitoring.

this buffering stuff is quite different from the way user interaction is setup with other daws. But luckily, even with values other daw's would see as "incredibly high", sawstudio feels solid and quick.

[Burkeville]

I was trying to explain the buffer concept to a recording class I was teaching. I am not sure if I did a good enough job. If anyone knows of any literature on this I would sure appreciate it.
Thanks

[Bob L]

Just about anything can cause Windows to interrupt my threads... even threads that are stamped as Time Critical can be stepped on when Windows decide to go off and have a picnic for x number of hundreds of milliseconds. :D

Oh well... it has been quite a journey to get things to try to remain stable at these low buffer settings which require service every few ms...

The buffer settings and latency measurements depend on all kinds of things internal and external...

Let's make it easy and just say the less buffers and the smaller they are... the better the latency... find a stable combination that gets the job done you are trying to do and move on to making music. :)

For VSTi synth latency while you are performing the combination of buffer number and size controls the latency you will feel... this also applies to the latency you will hear while live monitoring live inputs through the console channels.

For actual latency of where a signal gets dropped to the MT in recording, just the buffer size is the main element... and of course the AtoD conversion time is added in.

Bob L

[AudioAstronomer]

For actual latency of where a signal gets dropped to the MT in recording, just the buffer size is the main element... and of course the AtoD conversion time is added in.

Bob L


This is compensated for though, correct? If it were not, as I understand what you're saying; if I changed buffers mid project ther would be a sync difference. but I have not noticed this at all.

just trying to cover all the bases :)

[Bob L]

The recorded signal drop sync point is adjusted internally for the buffer size settings... this is not, however trying in any way to compensate for external converter and hardware latencies... but there should be no difference in the record signal sync points if you change buffer size midstream... however, your monitor through latency would change with the buffer size.

There have been thousands upon thousands of perfectly synced sessions recorded and mixed in SAWStudio long before anybody was concerned with latency issues and none of those recordings were ever thrown out because someone involved noticed a sync issue when they played back the newly overdubbed conga tracks... this issue, in my opinion, gets blown way out of proportion and truly has no real meaning when it comes to playing and recording real music... record and overdub and see if you hear a sync problem with the playback... it just is not an issue really. :)

Bob L

[AudioAstronomer]

this issue, in my opinion, gets blown way out of proportion and truly has no real meaning when it comes to playing and recording real music... record and overdub and see if you hear a sync problem with the playback... it just is not an issue really. :)

Bob L

I agree. thanks bob. Im done with this thread :)

[Naturally Digital]

Also anyone know if mastering houses accept 96k files? I'm thinking of doing my final bounce at 96k (from my Otari)

Jesse

Hi Jesse,

I think you'll find most mastering houses very happy to take 96K files. If they are good, then the less processing you do and the more they do, the better. The more resolution, the better. Use the 96K aspect to help narrow down your choices!

Dave.

[Jesse Skeens]

Hi Jesse,

I think you'll find most mastering houses very happy to take 96K files. If they are good, then the less processing you do and the more they do, the better. The more resolution, the better. Use the 96K aspect to help narrow down your choices!

Dave.

Unfortunatly I dont have a choice as the label would take care of that. I guess I was wondering if this was a common acceptance. Guess I'll give them both and let them use the 96k if they can.