[haiku-commits] Re: r34664 - haiku/trunk/src/add-ons/kernel/drivers/audio/hda
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 15 Dec 2009 11:29:40 +0100
On 2009-12-15 at 10:52:46 [+0100], Jérôme Duval <korli@xxxxxxxxxxxxxxxx>
wrote:
> 2009/12/15 <ingo_weinhold@xxxxxx>:
> > Author: bonefish
> > Date: 2009-12-15 01:21:43 +0100 (Tue, 15 Dec 2009)
> > New Revision: 34664
> > Changeset: http://dev.haiku-os.org/changeset/34664/haiku
> > Ticket: http://dev.haiku-os.org/ticket/4072
> >
> > Modified:
> > haiku/trunk/src/add-ons/kernel/drivers/audio/hda/hda_controller.cpp
> > Log:
> > * stream_handle_interrupt(): Fixed a misunderstanding of the SDnLPIB
> > (stream
> > descriptor n link position in buffer) registers. They contain "the number
> > of bytes that have been received off the link", which is not to be
> > confused
> > with the number of bytes that have been transferred by the DMA engine.
> > The interrupt is triggered when the last byte of the buffer has been
> > fetched
> > by the DMA engine, at which point the stream's LPIB is still somewhere in
> > the last buffer. So the interrupt handler could compute the wrong buffer
> > index, which would lead to the multi audio add-on filling the wrong
> > (currently being transferred) buffer, resulting in noisy sound. Now we
> > use
> > the DMA position. Should fix #4072.
>
> Great it's working for you! I remember though reading that SDnLPIB
> might still be of use on some ATI/VIA chipsets because the position
> buffer is sometimes inaccurate.
The LPIB is definitely more exact when it comes to the playing/recording
position, which is why it should be used for the frames/time computation. The
current method just leads to erratic performance times. I'll change that next.
Regarding whether a buffer has been transferred via DMA, the DMA position is
really the only safe information to use. I guess rounding the LPIB to the
closer buffer would also work in practice. At least as long a chipset creator
doesn't have the idea to prefetch more than half of the buffer.
> Maybe this patch fixes the nVidia hda
> problem with the workaround I introduced.
> I'll check today if playback and recording are still working correctly for
> me.
Yeah, please do.
CU, Ingo
Other related posts:
