[haiku-commits] Re: r34664 - haiku/trunk/src/add-ons/kernel/drivers/audio/hda
- From: Jérôme Duval <korli@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 15 Dec 2009 23:05:35 +0100
2009/12/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> Yeah, though I'd rather round the DMA position instead the LPIB, since the
> latter really doesn't have anything to do with the in-memory buffers (it's
> ahead for record and behind for playback, just as one would expect).
Seems logical.
>
> The interesting question is though, whether the interrupt is indeed early or
> the DMA position has just not been updated. Your DMA positions seem to be
> exactly 32 bytes behind the actual buffer end for both streams. What I could
> imagine is that the DMA transfer hitting the buffer end is already done
> (respectively has at least transferred the last bytes of the buffer) and has
> thus correctly triggered the interrupt, but the transfer updating the DMA
> positions has not happened yet. That would at least be the harmless case
> where rounding up would work as expected. But if the interrupt is really
> triggered early we would unleash the thread waiting in buffer_exchange()
> early, risking that it overwrites the not yet transferred data.
Well summed up. It's just hard to guess and to find out which things
to do with the actual values.
Last time I checked the offset with the actual buffer end was
dependent on the sample size.
Here is other information I noticed (I didn't find use for them): the
advertised delay for output and input is 15 samples.
The fifo size on the playback stream is 255 bytes, on the record
stream 159 bytes.
>
> I'll be playing a bit more with the driver and the multi audio node and
> commit something more robust, when I'm satisfied with the result.
With r34671, it goes pretty well (playback and record). I'll try to
test other sample rates and sample sizes.
Bye,
Jérôme
Other related posts:
