[alsa-devel] Slow SPI reads in ALSA causing mic recording error

[noman pouigt]

On Thu, Jun 14, 2018 at 5:48 PM, noman pouigt <variksla at gmail.com> wrote:
> On Thu, Jun 14, 2018 at 3:42 AM, Mark Brown <broonie at kernel.org> wrote:

On further debugging I found that I am getting xruns which explains the problem.

I am getting xrun in elapsed callback and ALSA is sending kill_fasync
to userspace
and userspace is calling prepare and trigger callback again.

I think I can check XRUN condition in prepare callback  and send
userspace a error
to let them know that XRUN happened.

>> On Thu, Jun 14, 2018 at 02:12:35AM -0700, noman pouigt wrote:
>>
>>> I have also used high priority workqueues but that didn't
>>> help either. Wondering if I can get some pointers to debug this?
>>> also if there any alsa-utility which can simulate closely audio flinger?
>>
>> You probably just need to ensure that you've got more than one period
>> so there's always one ready, increase min_periods or possibly make the
>> individual periods bigger.  It's normally going to be very hard to get
>> everything scheduled reliably if there's no margin for error, ensuring
>> there's some grace in case things run over will tend to be more robust.
>
> Thanks, but can you kindly explain how userspace application read which
> is happening via pcm_read (mmap) affects kernel SPI workqueue thread doing
> SPI read in a while loop i.e. causing SPI reads to get delayed?
>
> In kernel, we have two workqueues:
> 1. First to do SPI reads after trigger callback trigger and call
> elapsed callback
> once SoC gets more than period size.
> 2. Second to handle interrupts from DSP.
>
> First workqueue SPI reads is getting delayed based on the what application is
> reading data. In case of tinycap, we don't see much time difference
> between SPI reads
> but with AudioFlinger we see lot of time difference between consecutive SPI
> reads? How can application affect kernel threads and cause this delay?
>
> Please let me know where is this dependency coming from?