IPB

Welcome Guest ( Log In | Register )

> foobar2000 General Forum Rules

This is NOT a tech support forum.
Tech support questions go to foobar2000 Tech Support forum instead.

See also: Hydrogenaudio Terms of Service.

 
Closed TopicStart new topic
Request: Output buffer length below 50ms
markanini
post Dec 11 2011, 23:15
Post #1





Group: Members
Posts: 550
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



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.
Go to the top of the page
+Quote Post
kstuart
post Dec 13 2011, 04:17
Post #2





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



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 !
Go to the top of the page
+Quote Post
Peter
post Dec 13 2011, 11:30
Post #3


foobar2000 developer


Group: Admin
Posts: 3284
Joined: 30-September 01
Member No.: 84



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 (kstuart @ Dec 13 2011, 04:17) *
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.
Go to the top of the page
+Quote Post
kstuart
post Dec 13 2011, 18:39
Post #4





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



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.

This post has been edited by kstuart: Dec 13 2011, 18:41
Go to the top of the page
+Quote Post
kode54
post Dec 14 2011, 01:56
Post #5





Group: Admin
Posts: 4618
Joined: 15-December 02
Member No.: 4082



There is no such thing as a zero setting. That player is no doubt enforcing a minimum buffer size.
Go to the top of the page
+Quote Post
kstuart
post Dec 14 2011, 02:31
Post #6





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



QUOTE (kode54 @ Dec 13 2011, 17:56) *
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.
Go to the top of the page
+Quote Post
kode54
post Dec 14 2011, 03:49
Post #7





Group: Admin
Posts: 4618
Joined: 15-December 02
Member No.: 4082



Apparently, small hardware buffers with larger software buffers are appropriate for USB devices, somehow.
Go to the top of the page
+Quote Post
kstuart
post Dec 15 2011, 02:05
Post #8





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



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. wink.gif

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... rolleyes.gif
Go to the top of the page
+Quote Post
markanini
post Dec 15 2011, 07:05
Post #9





Group: Members
Posts: 550
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



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? smile.gif
Go to the top of the page
+Quote Post
Peter
post Dec 15 2011, 08:59
Post #10


foobar2000 developer


Group: Admin
Posts: 3284
Joined: 30-September 01
Member No.: 84



Yes, a fix can be added, but it definitely won't involve letting the user set such low buffer sizes.
Go to the top of the page
+Quote Post
kstuart
post Dec 15 2011, 18:57
Post #11





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



QUOTE (Peter @ Dec 15 2011, 00:59) *
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 ?
Go to the top of the page
+Quote Post
kode54
post Dec 15 2011, 20:16
Post #12





Group: Admin
Posts: 4618
Joined: 15-December 02
Member No.: 4082



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.)
Go to the top of the page
+Quote Post
kstuart
post Dec 15 2011, 22:17
Post #13





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



QUOTE (kode54 @ Dec 15 2011, 12:16) *
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.


Go to the top of the page
+Quote Post
markanini
post Dec 15 2011, 22:24
Post #14





Group: Members
Posts: 550
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



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.

Go to the top of the page
+Quote Post
kode54
post Dec 15 2011, 22:34
Post #15





Group: Admin
Posts: 4618
Joined: 15-December 02
Member No.: 4082



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.
Go to the top of the page
+Quote Post
TERIYAKI BUKKAKE
post Dec 15 2011, 23:58
Post #16





Group: Members
Posts: 20
Joined: 15-November 11
Member No.: 95165



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



Go to the top of the page
+Quote Post
melosoares
post Dec 30 2011, 13:30
Post #17





Group: Members
Posts: 3
Joined: 22-October 11
Member No.: 94636



+1 on the possibility of < 50 ms buffer

cool.gif

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.

smile.gif

Go to the top of the page
+Quote Post
mudlord
post Jan 1 2012, 18:24
Post #18





Group: Developer (Donating)
Posts: 811
Joined: 1-December 07
Member No.: 49165



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.


<)<
Go to the top of the page
+Quote Post
melosoares
post Jan 1 2012, 18:53
Post #19





Group: Members
Posts: 3
Joined: 22-October 11
Member No.: 94636



QUOTE (mudlord @ Jan 1 2012, 16:24) *
You didnt read.....
<)<



??

Go to the top of the page
+Quote Post
mudlord
post Jan 1 2012, 18:56
Post #20





Group: Developer (Donating)
Posts: 811
Joined: 1-December 07
Member No.: 49165



The quote explains why < 50ms is not possible.
Go to the top of the page
+Quote Post
kstuart
post Jan 1 2012, 20:08
Post #21





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



QUOTE (mudlord @ Jan 1 2012, 10:24) *
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
Go to the top of the page
+Quote Post
mudlord
post Jan 1 2012, 20:19
Post #22





Group: Developer (Donating)
Posts: 811
Joined: 1-December 07
Member No.: 49165



QUOTE (markanini @ Dec 15 2011, 15:24) *
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.


Go to the top of the page
+Quote Post
kstuart
post Jan 1 2012, 20:29
Post #23





Group: Members
Posts: 43
Joined: 4-April 11
Member No.: 89557



QUOTE (mudlord @ Jan 1 2012, 10:56) *
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.

This post has been edited by kstuart: Jan 1 2012, 20:31
Go to the top of the page
+Quote Post
Peter
post Jan 1 2012, 20:51
Post #24


foobar2000 developer


Group: Admin
Posts: 3284
Joined: 30-September 01
Member No.: 84



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.
Go to the top of the page
+Quote Post

Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th September 2014 - 03:57