The following is a transcript from a conversation I had with Sampo, one of the Ardour developers in which he explained to me exactly how audio buffering works. People like this are what make linux so awesome.
I don’t really understand the period/buffer settings, I’ve got them to bring the latency down.
tcpsyn: the buffer size means how many samples at a time jackd retrieves from the sound card and the size of the buffers it sticks to jackd clients for processing
and how does that affect perfomance vs latency?
tcpsyn: so the smaller the buffer is, the more jackd needs to switch between clients per “amount of real world time”
and the lower the latency
since it’s doing it more often?
no to the second question
tcpsyn: the bigger the buffer is, the more .. buffering, jackd needs to do. so it needs to wait to gather all these samples, run them through all the applications and feed those samples back to the interface
and the more latency… ?
tcpsyn: the larger the buffer is = the larger chunk of real world time it represents
tcpsyn: and more latency
well that makes sense.
tcpsyn: the number of periods refers to lower level hardware buffering
tcpsyn: but it also affects latency
tcpsyn: it basically means how many of these buffers the sound card uses by itself. the more of these there are, the less chance of having xruns or even worse — missed samples.
so higher is better
tcpsyn: and more latency
tcpsyn: but the number of periods is not as simple as that
tcpsyn: how well it works, and how it actually works is device and driver dependent
tcpsyn: it’s more like, there will be a good value for your device and you should stick with it
and do either of those affect cpu cycles?
tcpsyn: the lower the buffer size, the more switching between applications the system needs to do
tcpsyn: say you are running at mythological 1/4 of a second frames and you have two applications using jack
tcpsyn: that would mean that jackd would need to run both applications four times per second to create a steady flow of audio
tcpsyn: so it means 4 * 2 (the number of application) switches between applications per second (this is a gross simplification though)
tcpsyn: if you would increase the buffer size to an amount of frames which would be equal to 1/2 of a second
tcpsyn: there would only be 2 * 2 switches between applications per second
tcpsyn: and the closer to zero the buffer size gets, the more predominant the time it takes to switch between applications get (as compared to the time to actually process the audio data)
I have to read this like 500 times.