Audio latency not as simple as it looks.
Audio latency not as simple as it looks. Posted on: 24.06.2010 by robert chanda Been reading up on writing audio software (Audio Anecdotes) and come across something that surprised me about audio latency.Usually, when you set up an audio device you get a slider that sets the "buffer size", often measured in milliseconds. That represents the amount of time the audio hardware can output until it has consumed all the data in the buffer. Simple enough. But audio buffers are actually implemented as a Ring Buffer. There are two markers, the Read point and the Write point, and they follow each other around the circular buffer, where the Write point can never overtake the Read point. The latency of the audio in that situation is the distance between the two markers - that's the amount of sound that has to be played before any new sounds can be sent. Often, this distance is way less than the size of the buffer - that's problem no.1 in calculating your latency: Buffer size only control the maximum latency in the system. Making your buffer smaller does little to the average latency, that actual use case you are trying to control. The second problem is that, with fast CPUs being able to fill audio buffers way faster than they are consumed by the audio hardware there is a trick where the software has filled a buffer with audio data to be played. Suddenly the user tweaks a parameter or presses a button that means different audio should now be playing. The CPU can ignore the Write position, jump back into the already written audio data and start rewriting old audio with new values. There's no need for the system to wait for the buffer to be emptied before generating new audio. The latency for this system is much less than the size of the buffer and is only proportional to the speed of your CPU. The faster your CPU, the further back in time it can jump, start refilling and still be ahead of the Read position. So, setting your buffer size to the minimum before it crackles is no longer the correct thing to do. Just pick a healthy amount and let the software do it's job. Yes, this really needs diagrams to explain it properly... (Not that I can prove that any particular piece of software actually uses this technique, but it's definitely out there in the wild) | |
| robert chanda 24.06.2010 | Been reading up on writing audio software (Audio Anecdotes) and come across something that surprised me about audio latency. Usually, when you set up an audio device you get a slider that sets the "buffer size", often measured in milliseconds. That represents the amount of time the audio hardware can output until it has consumed all the data in the buffer. Simple enough. But audio buffers are actually implemented as a Ring Buffer. There are two markers, the Read point and the Write point, and they follow each other around the circular buffer, where the Write point can never overtake the Read point. The latency of the audio in that situation is the distance between the two markers - that's the amount of sound that has to be played before any new sounds can be sent. Often, this distance is way less than the size of the buffer - that's problem no.1 in calculating your latency: Buffer size only control the maximum latency in the system. Making your buffer smaller does little to the average latency, that actual use case you are trying to control. The second problem is that, with fast CPUs being able to fill audio buffers way faster than they are consumed by the audio hardware there is a trick where the software has filled a buffer with audio data to be played. Suddenly the user tweaks a parameter or presses a button that means different audio should now be playing. The CPU can ignore the Write position, jump back into the already written audio data and start rewriting old audio with new values. There's no need for the system to wait for the buffer to be emptied before generating new audio. The latency for this system is much less than the size of the buffer and is only proportional to the speed of your CPU. The faster your CPU, the further back in time it can jump, start refilling and still be ahead of the Read position. So, setting your buffer size to the minimum before it crackles is no longer the correct thing to do. Just pick a healthy amount and let the software do it's job. Yes, this really needs diagrams to explain it properly... (Not that I can prove that any particular piece of software actually uses this technique, but it's definitely out there in the wild) |
| Herschel January 24.06.2010 | Good find Limey. More reading material |
| Leeanna Ayla 24.06.2010 | My latency set itself at 30ms when I installed Traktor on my MBP. I forgot to change it for about a month, mostly because I never noticed any thing wrong with my audio. |
<< Back to Reviews of DJ equipment Reply