Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Request: Output buffer length below 50ms (Read 20534 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Request: Output buffer length below 50ms

I like to use foobar2000 as a system wide audio processor(EQ and crossfeed) via foo_record. This works very nicely for online music services but when viewing video lip sync appears off. If it were be possible to set the output buffer length to 20-25ms I believe lip sync would be largely improved and my i5 system would likely handle it without degraded sound quality. Please consider a toggle in advanced config menu If you wouldn't want to add such a esoteric setting to the main output preferences page.

Request: Output buffer length below 50ms

Reply #1 –
It's interesting that I was searching if someone had requested this before, and found that it was requested only one day before !

In my case, I need this for an entirely different reason, and one which causes me to not be able to use foobar2000 in its current state.

Basically, I use an asynchronous USB DAC where output buffering has the opposite of the usual effect, i.e. the more latency, the more tendency to pops and dropouts.

So, I am currently using another player that happens by coincidence to have its buffer size (latency) in its config file, where I can happily set to zero, and then playback is just fine.
The designer of this USB DAC has stated:

Quote
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.

Thanks !

Request: Output buffer length below 50ms

Reply #2 –
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.

Quote
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".
These devices appear to have rather dodgy interaction with WASAPI. The correct solution for this issue is NOT using WASAPI rather than turning the buffer size down - which doesn't even properly help to begin with (does not entirely eliminate glitches) and mutilates foobar2000's resistance against file reading lag.

Quote from: kstuart on
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 "zero latency", whatever you think you've done with another player, it's certainly not "zero" latency, just whatever lowest value allowed by the driver.

Also you quite misunderstood what the DAC developer person meant:
Quote
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.
There is no need to have buffers of any specific size when low latency isn't required. Software audio playback IMPLIES some level of buffering. In fact, this quote explicitly says that small buffers are more prone to glitching, which I can agree with, but you seem to have drawn your own opposite conclusions from it.
Microsoft Windows: We can't script here, this is bat country.

Request: Output buffer length below 50ms

Reply #3 –
The footbar2000 buffer slider:

- When using sound card built into the motherboard, connecting to amp with SP/DIF:

Moving the slider to the right (increase buffer) removes glitches, moving to left makes it worse.

- When using USB DAC:

Moving the slider to the right (increase buffer) increases glitches, moving to left removes them, but at the far left end ("50") there are still some, as if the slider did not let the value go far enough down.

In another software player, instead of a slider, there is a numerical value in the config file, default is 1000, IIRC.

With USB DAC, as I set that to lower values, there are less glitches, and at values below 50, the glitches go away.  "0" is working fine in that player.

That is the on-hands experience of myself and posters to other forums.

I will be happy to alpha-test a version with a change for this.

PS  Asynchronous USB DACs work by doing the timing entirely in the DAC to a new clock source in the DAC.  So, the soffware buffers that would normally be helpful, are here counter-productive, since they require the hardware buffer to store more and more data, and possibly overflow.

Request: Output buffer length below 50ms

Reply #4 –
There is no such thing as a zero setting. That player is no doubt enforcing a minimum buffer size.

Request: Output buffer length below 50ms

Reply #5 –
Quote from: kode54 on
There is no such thing as a zero setting. That player is no doubt enforcing a minimum buffer size.

4 10 15 and 20 all worked fine...

But it is interesting that some are so used to "more buffer is better" that they want to feel that it must be correct for all hardware configurations.

Request: Output buffer length below 50ms

Reply #6 –
Apparently, small hardware buffers with larger software buffers are appropriate for USB devices, somehow.

Request: Output buffer length below 50ms

Reply #7 –
Here is what another user reported in 2010 on the forum of a yet different (third) music player:
Quote
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).


Through the long thread, the tech support guys give all the usual shot-in-the-dark suggestions (just like Internet Provider tech support will tell you to "clear all your cookies in your browser" when their Internet Backbone line has crashed.

This is only one of several reports I have seen on the web - clearly, all other users never even tried making the buffering lower, since "everyone knows that buffers should be up as much as possible" for all hardware in all situations... 

Request: Output buffer length below 50ms

Reply #8 –
FWIW, in my experiments with Virtual Audio Cable and VSTHost I was able to set an MME output buffer ridiculously low and clicks and pops would certainly start to dominate the output. The lowest I could get away with was 25ms which only clicked/popped if I did any heavy processing at the same time like video transcoding. Now if kstuart's hardware is fairly common  and truly benefits from lower output buffer I can't see why a fix can't be added in fb2k when fixes are included for other specific cards such as the Asus Xonar. But ultimately it's the decision of the developer i.e. Peter, is'nt it?

Request: Output buffer length below 50ms

Reply #9 –
Yes, a fix can be added, but it definitely won't involve letting the user set such low buffer sizes.
Microsoft Windows: We can't script here, this is bat country.

Request: Output buffer length below 50ms

Reply #10 –
Quote from: Peter on
Yes, a fix can be added, but it definitely won't involve letting the user set such low buffer sizes.


Why not - in advanced settings ?

Request: Output buffer length below 50ms

Reply #11 –
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.)

Request: Output buffer length below 50ms

Reply #12 –
Quote from: kode54 on
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.)

What you are missing is that the functionality implemented in the software buffer is not needed at all in some hardware configurations, in fact, it just interferes with the hardware.

The hardware provides its own clock and merely stores the data stream in its own internal buffer (not the one you can address from the player), and then recreates the data stream.  This is called "asynchronous".

Everything you say was 100% true in 1999.... and no longer.


Request: Output buffer length below 50ms

Reply #13 –
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.

Request: Output buffer length below 50ms

Reply #14 –
Yes, a software buffer is needed. While the output may be asynchronous, foobar2000 cannot guarantee smooth, uninterrupted output with such small buffer sizes. Some formats may decode in larger chunks, which still need to be broken down. Some formats may also take longer to decode some parts than others, which would cause underruns.

Without a large buffer to constantly feed the small hardware buffer, the system driver receiving data through the WASAPI interface will underrun, and there will be dropouts. At buffer sizes smaller than 50ms, these are heard as buzzing.

Request: Output buffer length below 50ms

Reply #15 –
Well,foo_record input from e.g. DirectSound to Foobar2000.
My sound driver can do WDM to MME or WDM to ASIO.
So I see why you use Virtual Audio Cable
But its feel like ASIO vs ASIO4ALL to me

Anyway your img is char?
with P90



Request: Output buffer length below 50ms

Reply #16 –
+1  on the possibility of < 50 ms buffer

 

I also have an asynchronous USB DAC that pops with wasapi / foobar.

I do love foobar but had to change media player because of this issue. DS is not an option to me because it´s not bitperfect.

Other media players do have better wasapi output with perfect no-pop playback (<50ms buffer)... nevertheless I would love to see it in foobar also.

 

Request: Output buffer length below 50ms

Reply #17 –
You didnt read.....
Quote
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.


<)<

Request: Output buffer length below 50ms

Reply #19 –
The quote explains why < 50ms is not possible.

Request: Output buffer length below 50ms

Reply #20 –
Quote from: mudlord on
You didnt read.....
Quote
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.


That was in the context of the OP's interest in foo_record and realtime processing.  Both of us are just interested in lower buffer size for USB DACs

Request: Output buffer length below 50ms

Reply #21 –
Quote from: markanini on
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.


Request: Output buffer length below 50ms

Reply #22 –
Quote from: mudlord on
The quote explains why < 50ms is not possible.

Just the opposite - the quote says that it is possible, and that "you will run into problems".

The problems only exist with adaptive transfer - asynchronous transfer actually works better with lower latency.

We know this from using another player where it allows setting it down to zero.  The observed latency was 0.67 ms and it played just fine.

Not all hardware has the same requirements, and also - not all hardware has the same requirements.

PS  To pre-emptively answser the inevitable reply "then just use that other player", foobar2000 has some unique qualities, and some unique component add-ons.  This makes me think that USB DAC owners may want to use foobar2000, and it would be better for everyone if there is an advanced setting that allows that output buffer slider to go down to zero.  Thanks.
 

Request: Output buffer length below 50ms

Reply #23 –
Let me try to explain this one more time:

foobar2000 CANNOT handle low latency playback. You can keep wishing or mis-interpreting my posts, but that won't change the facts.

There is no such thing as "zero latency playback". It exists only in your imagination. Any software that claims such thing is lying to you.

USB DAC problems CAN be worked around, but by using two stages of buffering rather than minimizing the use of buffering, so you get what you want regardless of configured buffer length. This will require an update to the WASAPI component.

Topic locked to prevent further pseudo-discussion.
Microsoft Windows: We can't script here, this is bat country.