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

[Clemens Ladisch]

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?


Regards,
Clemens