[haiku-development] Re: HDA
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 09 Nov 2012 14:29:22 +0100
pulkomandy wrote:
> On Thu, Nov 08, 2012 at 07:18:13PM -0500, Sean Collins wrote:
> > It sucks on windows, and for some reason currently haiku will
> > adjust up automatically for some big buffer times. I think a default
> > setting is good, and a panic adjustment is fine, but honestly, the
> > less the system intervenes to make buffers longer and latter, the
> > better. the bottle necks and performance issues should be adressed,
> > not covered in buffer bloat.These threads should be handled at near
> > the top of the priority heap, side effects from them not being so,
> > generally aggravate users.
>
> The increasing buffer size is actually a feature. It happens because
> media nodes are requesting it. Most applications use the
> B_INCREASE_LATENCY mode, which does just that. We already hacked it so
> the maximum buffer size is bounded, and it will start dropping samples
> at some point, which it should not do.
The mode drops buffers, when they are too late. And that is what it should do.
It *also* increases the latency, so that future buffer lateness is less likely.
> This mode is actually meant for
> non-real-time audio, where you are for example saving things to disk.
That is incorrect. B_RECORDING is the mode to be used for recording.
B_INCREASE_LATENCY is the standard mode for playback, since in most playback
applications the latency doesn't matter much, but dropping buffers is very
annoying. For other kinds of applications dropping buffers may be less
problematic while a low latency is paramount.
> If that's a problem for you, then it should be fixed in applications to
> use the proper mode, please report that to the affected application's
> developpers. In the meantime, you can change the mode with Cortex.
Agreed.
CU, Ingo
Other related posts:
