Latency, Buffer Size & USB transfer mode
Mar 11, 2012 at 6:49 AM Thread Starter Post #1 of 9

Mauricio

500+ Head-Fier
Joined
Feb 4, 2012
Posts
634
Likes
37
In asynchronous data transfer via USB between computer and DAC, what is the best buffer configuration for reduced latency and increased sound quality?  A big software (e.g. in Foobar) buffer or a small buffer?  Kindly advise.
 
Mar 11, 2012 at 8:38 AM Post #2 of 9
To reduce latency (which doesn't make much sense in an audio player) reduce the buffer size as much as possible. If there are glitches increase the buffer a bit.

Otherwise leave the default (1000 ms).
 
Mar 11, 2012 at 10:03 AM Post #4 of 9
An audio player like foobar2000 reads a portion of the file, decodes it, applies DSP effects (if any) and puts the result in a buffer.
 
On a fast computer, even a large buffer is filled within a few milliseconds or less. However, if your computer is slow or currently busy (e.g. copying files, decoding a HD movie and so on) filling the buffer might take longer.
 
The samples in the buffer is what is being played by the soundcard/interface. Now if the buffer is very small and your computer doesn't fill it fast enough you'll run into audio glitches such as stuttering, drop-outs, clicks. Additionally, too short buffers will cause certain visualizations to stop working and also limits the DirectSound fade in/out durations.


Simple example:

Assume you have a full buffer of 1000ms. Once 25ms have been played, there are still 975ms of audio in the buffer before there will be a glitch. That should be enough time for even slower or very busy computers to refill the buffer.

With a much smaller buffer, lets say 50ms, your computer has to refill the buffer in under 25ms or a glitch will occur. Additionally, the smaller the buffer, the higher the overhead: in the example above, the player could refill the buffer with a single big chunk (e.g. 500ms) once it is half-empty, but with the small buffer it needs to refill the buffer maybe 20 times (20*25ms = 500ms) or even more often with very small chunks.

 
Mar 12, 2012 at 1:35 PM Post #5 of 9
There is another viewpoint regarding this matter. Filling a large buffer causes a disruption in the CPU/RAM/power system. A smaller buffer means more frequent but smaller disruptions and may be preferable from the standpoint of software induced jitter.
 
I set the buffer in Foobar to the smallest allowed (50 ms) and this sounds better IMHO. I avoid DSP and visual effects where possible.
 
Mar 12, 2012 at 1:39 PM Post #6 of 9
Quote:
There is another viewpoint regarding this matter. Filling a large buffer causes a disruption in the CPU/RAM/power system. A smaller buffer means more frequent but smaller disruptions and may be preferable from the standpoint of software induced jitter.
 
I set the buffer in Foobar to the smallest allowed (50 ms) and this sounds better IMHO. I avoid DSP and visual effects where possible.


Could you provide any sources? Just from the way you described it, it sounds like an unsubstantiated myth, especially since it concerns jitter.
 
Mar 14, 2012 at 5:10 PM Post #8 of 9
This is a very interesting site. The science is there but also listening tests.


Nope. Seriously, it's a ridiculous site and what science? I don't see the science.
 
Mar 14, 2012 at 6:38 PM Post #9 of 9

Users who are viewing this thread

Back
Top