Slow SPI reads in ALSA causing mic recording error

Slow SPI reads in ALSA causing mic recording error

[noman pouigt]

Hello Folks,

I have a DSP hardware connected over SPI
to SoC with extra interrupt line.

I am getting buffer overrun problem in DSP
while doing MIC recording. SoC SPI consecutive reads
are two slow and it is not able to empty DSP buffers
in time which causes DSP to issue overruns interrupts
to SoC and causes bad mic data recording.

ARECORD properly records mic data but when I try to use
AudioFlinger(android) then I see buffer overrun issue in
DSP. Period size is same in both arecord and AudioFlinger case.

system: arm64, latest mainline kernel, latest alsa-lib

I have below platform ops
static const struct snd_pcm_ops platform_ops = {
     .open    = platform_open,
     .ioctl      = snd_pcm_lib_ioctl,
     .pointer  = platform_pcm_pointer,
     .mmap    = snd_pcm_lib_default_mmap,
     .page      = snd_pcm_lib_get_vmalloc_page,
 };

What baffles me is that consecutive SPI read(while loop
in a workqueue) doesn't have any relation with userspace
as it is interrupt driven (DSP interrupt) but still with
audio flinger overrun happens. In the workqueue, between
SPI reads, driver calls  elapsed function to notify the userspace
to read 1 period data whenever data crosses period boundary.
I don't think that causes any issues. Aforementioned workqueue
stops only when userspace closes it so I don't know how
userspace application can slow down SPI reads?

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?

Thanks,

Re: Slow SPI reads in ALSA causing mic recording error

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 621 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Slow SPI reads in ALSA causing mic recording error

[noman pouigt]

On Thu, Jun 14, 2018 at 3:42 AM, Mark Brown <broonie@kernel.org> wrote:
> 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?

Re: Slow SPI reads in ALSA causing mic recording error

[noman pouigt]

On Thu, Jun 14, 2018 at 5:48 PM, noman pouigt <variksla@gmail.com> wrote:
> On Thu, Jun 14, 2018 at 3:42 AM, Mark Brown <broonie@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?