[haiku-development] Re: HDA
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 8 Nov 2012 09:25:59 +0100
Am 08.11.2012 um 08:33 schrieb pete.goodeve@xxxxxxxxxxxx:
> On Wed, Nov 07, 2012 at 09:29:40PM +0100, Julian Harnath wrote:
>>
>> Still, I'm running my system with the patch applied and lowered HDA
>> buffer size. I'm currently porting MilkyTracker to Haiku, and having
>> low-latency audio is more important to me than occasional glitches
>> (however annoying they are)... entering notes with hda-driver's default
>> latencies just feels awkward. As comparison: imagine using Wonderbrush
>> and having 100+ milliseconds delay between moving your mouse when
>> drawing and getting a reaction on screen...
>> I'd definitely be interesting in tracking down the issues that make the
>> large buffers necessary...
>
> And I wonder a bit how necessary they still are. It was as trivial as
> I hoped to change the parameters (two lines in MultiAudioDevice.cpp) and
> I'm now getting 15ms latency with no detectable glitching. (Haven't
> tried loading the system down, but for my use I should never need to get
> into such a situation.) This is without the priority patch, which I
> haven't yet got around to trying. Don't know how good this would be with
> the latest build on a single-CPU box (my older Haiku machine's hard drive
> is again a bit sick at the moment) so it might not be a general solution.
>
> I pretty arbitrarily chose 4 buffers of 1024 sample frames, but I do
> think it would be nice to make this adjustable without a recompile.
> Would it be worth my while to add in a settings-file facility like
> auich has? Or do people think this will be unnecessary eventually?
It could very well be not necessary anymore. The reasons could be improvements
in Haiku, or it could be we are all using faster computers. Also keep in mind
that nightlies have serial debugging enabled and the kernel is compiled in
debug mode, for the alpha as well (but no serial debugging by default, there).
In any case, ideally the driver would not hard-code the buffer size, but figure
it out dynamically. I know it does depend on some factors, but maybe not much
else besides sampling frequency and bit depth. A settings file may not be a bad
idea, it can help users now, and it can also help in the future for cases where
the automatic buffer size mechanism fails for whatever reason, once it has been
implemented.
Best regards,
-Stephan
Other related posts:
