[haiku-commits] Re: r34664 - haiku/trunk/src/add-ons/kernel/drivers/audio/hda

2009/12/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>> 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.

This doesn't work well for playback with your change. Ticks/crackles
occur regularly. Here are the position and lpib values:
KERN: hda: stream (id:1) position: 81888, lpib: 81664
KERN: hda: stream (id:2) position: 98272, lpib: 98304
KERN: hda: stream (id:1) position: 163808, lpib: 163584
KERN: hda: stream (id:2) position: 49120, lpib: 49152

Interrupts should happen respectively at 81920 and 163840 for the
first stream (32 bits, 192kHz), 49152 and 98304 for the second stream
(24 bits, 96kHz).
For record, the lpib and interrupts are accurate, the position is not.
For playback, both position and lpib aren't accurate.
To have correct buffer cycles, and good playback and record, I had to change to:
    stream->buffer_cycle = 1 - position / bufferSize;
or
    stream->buffer_cycle = ((position + (bufferSize >> 1)) /
bufferSize) % stream->num_buffers;

Rounding the LPIB to find out the buffer cycle seems to way to go.
BTW which chipset do you own ?

Bye,
Jérôme

Other related posts: