The small hardware buffer is more challenged as the sample rate increases and if the host is late in adjusting its data payload then over/under runs become possible (this is almost certainly what you are hearing). For a simplex operation such as a playback only system, there is no need to have buffers of any size as latency isn't an issue.
If you search the web, you will find numerous owners of asynchronous USB DACs who state: "I discovered that if I turned the foobar2000 buffer down to its lowest point of 50, that reduced the pops and dropouts, but did not entirely eliminate them".
So, simply allowing this slider to go all the way down to zero would help both people like the previous poster who need low latency (this would include music performers), and also USB DAC users.
There is no such thing as a zero setting. That player is no doubt enforcing a minimum buffer size.
The only way I can get it to go properly is with buffering set to minimum (50ms) and even then I get the odd click and pop coming through per song. If I set it to any higher buffer value it gets quite bad, eventually stuttering badly. ...The tantalising thing is that whatever is going on depends on the buffer time, and maybe 25 to 40ms would work fine - 50ms almost does. I saw a reference to this with another player on another site. I've no idea why there should be a relationship, but there is....Another player seemed to work ok here when it was altered to be able to source the regular 10ms packets dCS seem to want (over the standard USB driver).
Yes, a fix can be added, but it definitely won't involve letting the user set such low buffer sizes.
A future version will likely implement a tiny hardware buffer, while the rest of the configured buffer is implemented purely in software. If that's not playback equivalent to the 50ms or smaller buffer you already want, with the added file I/O and decoding safety of the added software buffer, then something is wrong with your hardware.(That is how the ASIO output component is already implemented, by the way.)
foobar2000 is a player, not a realtime processor. It was not designed to handle such latencies. You will run into problems due to how foobar2000's internals work; on top of that, I doubt you will ever achieve latencies acceptable for your purposes because foo_record and your DSPs introduce latencies on their own.
You didnt read.....<)<
You didnt read.....Quotefoobar2000 is a player, not a realtime processor. It was not designed to handle such latencies. You will run into problems due to how foobar2000's internals work; on top of that, I doubt you will ever achieve latencies acceptable for your purposes because foo_record and your DSPs introduce latencies on their own.
kstuart, if what your saying is correct could you point to a technical document or SDK that confirms it? Might be a bigger chance to see it implemented that way.
The quote explains why < 50ms is not possible.