[alsa-devel] fsl_ssi.c: Roberto's problem: ssi hangs after some number of samples

[Caleb Crome]

On Thu, Nov 5, 2015 at 2:08 PM, Roberto Fichera <kernel at tekno-soft.it> wrote:
> On 11/05/2015 10:34 PM, Caleb Crome wrote:
>> On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel at tekno-soft.it> wrote:
>>> On 11/05/2015 12:30 PM, Fabio Estevam wrote:
>>>> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel at tekno-soft.it> wrote:
>>>>
>>>>> Following your suggestion, I've increased the buffer size to 2K and set the period to fifo_length - 2 (13),
>>>>> with that I'm now running substantially smooth except 3 EVTERR on RX DMA over 4 million of interrupts.
>>>>>
>>>>> Thanks Nicolin! I'm quite happy now!
>>>> That's good progress, Roberto.
>>>>
>>>> It would be nice if you and Caleb could post the patches to the mailing list.
>>>>
>> Yes, when I get something quite solid, I'd like to submit it all to
>> the list, and hope to get it into the kernel so nobody else has to go
>> through this pain again.
>>
>>> Indeed! Now the TDM is stable, I've also found the reason of the EVTERRs, which was related to some stale
>>> code I've used to enable and disable both RDMAE and TDMAE bits to try to reset the transfers.
>>> Once removed that code everything is looks ok now.
>>>
>>> Regarding patches, well, from my side there isn't nothing special compared to the original fsl_ssi.c code.
>>> I'm basically running against a very skinny fsl_ssi.c version, I've just setup a bit larger DMA buffer, from
>>> 16bytes to 2K, and now reduced the DMA period to 8 because I'm mostly comfortable with that size to simplify
>>> sampling exchange against DAHDI subsystem within my DMA callbacks.
>>>
>>> In a few words, my problem was related due to a DMA buffer too small.
>>>
>>> What eventually might be interesting to have is the INTRMASK and EVTERR DMA setting to trigger DMA
>>> related errors, but I guess this need to be discussed elsewhere.
>> I have implemented roberto's patch on the 4.2 kernel, and I get a huge
>> number of EVTERR interrupts.  Something like 7200/second at 16kHz
>> sample rate.  But strangely, the audio seems to be correct.
>
> I've notice that clearing the EVTERR bit seems restarting the given SDMA.
>
>> My patch is slightly different in that it just enables EVTERR for all
>> channels, not just for the SSI.  Might as well see if there are any
>> other problems.
>
> Oh yes! This will overload the SDMA isr.

It didn't seem to.  There didn't seem to be any other DMA happening in
my system, definitely none that made the EVTRR trigger.  However, I
changed it back to the way you had it.  No differences, still got a
TON of EVTERRs.

> How bigger is your audio buffer?
> In your case I guess you will need something like 16KHz * 16 channels *
> 2 bytes (16bits) = 512K minimum.
> I would try to start from 1MB or maybe more.

That's 2 seconds of audio!  We definitely need less buffering than
that.    We pretty much need a latency of 100ms, worst case, or 1600
frames, or 51,200 bytes.

I did change the max buffer size to 1MB though, but I'm not sure how
much is actually being used.

>
>>
>> And it puts the stats file at
>> /sys/kernel/debug/20ec000.sdma/stats
>>
>> When I aplay a file for 10 seconds I get ~366 EVTERR interrupts.
>> When I arecord for 10 seconds, I get 1 EVTERR interrupt
>> When I run my application for 10 seconds, which does full duplex, I
>> get 72703 EVTERR interrupts, but the data integrity checks out okay.
>>
>> Interstingly, when I enable dual fifo, it goes from about 7200
>> EVTERR's/sec to about 18 EVTERRs/sec.  Much better, but still a long
>> way from working perfectly.
>>
>
> Cyclic DMA is particular scatter-gater DMA list dedicated for repetitive
> tasks looping over the same buffer, so audio.
> The associated callback is triggered every period (fifo_depth-2) but the
> job will last only when the buffer is
> filled in the request length. All this "tasks" will be managed by SDMA
> ISR. You can follow the SG_LOOP flag if you
> want understand more.

I don't want to understand more.  I just want it to work  :-)



>
>> When I get a 'hang' from my application (no more portaudio callbacks),
>> I'm actually getting repeated calls to sdma_prep_dma_cyclic, though I
>> don't know how that call gets triggered.  But once that starts
>> happening, no more audio data gets through.
>
> If I remember correctly portaudio has a thread that controls your
> callback that receive/play all samples, but I don't remember if the
> callback is responsible to stop recording or playing in case of error.
> I've to check this in my last app.
>

Yeah, it does normally restart by itself.