[alsa-devel] [RFC PATCH (alsa-lib)] pcm: Modify check condition in snd_pcm_sw_params_set_avail_min

[Koro Chen]

On Thu, 2015-09-03 at 10:14 +0200, Clemens Ladisch wrote:
> Koro Chen wrote:
> > On Thu, 2015-09-03 at 09:08 +0200, Takashi Iwai wrote:
> >> On Thu, 03 Sep 2015 05:20:54 +0200,
> >> Koro Chen wrote:
> >>> When we use a ping-ping buffer in capture, and if hw_ptr reported
> >>> at IRQ is a little smaller than period_size:
> >>>
> >>> |xxxxxxxxxxxxxxxxxxxxxxxxxxxx--|-----------------------------|
> >>>                             hw_ptr < period_size
> >>
> >> How this happens?  The period size is the size where irq (or wakeup)
> >> wakes up for read/write.  Why the driver wakes up even if there is no
> >> enough data?
> >
> > Yes it is odd to what we would normally expect. Due to our HW design,
> > when irq comes, audio HW actually has collected a full period of data,
> > but there is a buffer between the audio HW and memory, so at that moment
> > some samples are still in the buffer, not on the memory.
> 
> Please note that ALSA (both the kernel and the userspace API) requires
> that after a period interrupt, the _complete_ period has been read from/
> written to the memory buffer.  This is needed because the interrupt is
> the mechanism that synchronizes software and the DMA controller.
> (Except when using the NO_PERIOD_WAKUP flag, but you cannot rely on the
> software using it.)
> 
> 
> Typically, any buffering is done inside the DMA controller, which also
> issues interrupts, so this problem should not happen with correctly
> working hardware.
> 
> (On PCI systems, writes to system memory can be buffered, but if the
> interrupt handler does a read from a device register, the PCI memory
> ordering rules ensure that all DMA accesses started before the interrupt
> are finished before the read.)
> 
> 
> How does your hardware work?  I guess that whatever component does the
> buffering is independent of the component that generates interrupts, and
> it does not enforce any memory ordering either?  And there isn't
> a mechanism to flush the buffer?
> 
Yes, your guess is correct...our IRQ hardware is just a separated timer
which is not related to any memory control. I am not sure if there is
any way to manipulate the buffer and I will check it. Thanks for your
advice! 
> 
> Regards,
> Clemens
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel