[haiku] Re: A little audio survey
- From: pete.goodeve@xxxxxxxxxxxx
- To: haiku@xxxxxxxxxxxxx
- Date: Tue, 19 Jul 2011 19:06:00 -0700
On Tue, Jul 19, 2011 at 09:18:46PM +0200, Axel Dörfler wrote:
> pete.goodeve@xxxxxxxxxxxx wrote:
> > Some installations will not produce sound immediately after boot up,
> > but
> > sound will start working later. This appears to somehow be a result
> > of
> > a large (default) buffer size in the driver. [....]
> > The large buffer size also results in a latency of ~1/5 sec.
>
> Since HDA has similar issues, I guess it's not driver related at all.
Yes, I think so too. What I'm wondering is if/how buffer size relates to
the problems. Are buffers large for other drivers -- preventing crackles,
but implying longer latency (and somehow not causing startup silence)?
Or are the buffers small, but the crackles don't show up for some reason?
> I would also assume that auich worked nicely on BeOS a while back -
> Jérôme could clarify.
What's the history here? It was written for BeOS originally?
> I have HDA and didn't have any issues for a long time, but since a few
> months, audio has problems like being silent at first.
This is also a bit odd, because the problem has been around for me ever
since I first installed Haiku -- over two years on Scott's old Thinkpad
that requires OSS, and about a year, I guess, for the auich box (Dell).
>
> I think the main issue is somewhere in the media kit, possibly some
> broken latency computation or something similar.
(Whimper... (:-/)) This is the battle I was fighting for most of this
year. [see the saga in #7285...] Latency is certainly currently broken
-- if I could only convince anyone else...! The mods I made to the
latency computation improve things on my machine, but they don't cure
the essential problem, which is that 'blackouts' of ~8-10 msec occur,
and these can delay a buffer anywhere in the chain. If a buffer doesn't
arrive in time, you're going to get a crackle. (My fixes just prevent
latency increasing without limit when a buffer is late.)
The blackouts seem highly causally related to the display. I now have
a command-line only version of ToneProducer (with latency reporting);
if I run this remotely, so the display is not being touched, it is
quite clean -- I can run forever without a glitch. If I run it from
a Terminal, it's usually the same. Any slight movement of any window
though -- or possibly even just the mouse (?) -- can cause a blackout.
Interestingly, it may be strictly window related. If I run the teapot
and am careful not to move any window at all, I never seem to get a blackout.
Even if I use the mouse strictly within the teapot window, it doesn't
seem to glitch.
That's all I have for now. Not sure where to look from here.
-- Pete --
Other related posts:
