Re: fsl_ssi.c: Roberto's problem: ssi hangs after some number of samples

[Roberto Fichera <kernel@tekno-soft.it>]

On 11/03/2015 01:56 AM, Caleb Crome wrote:
> On Mon, Nov 2, 2015 at 10:03 AM, Roberto Fichera <kernel@tekno-soft.it> wrote:
>> On 11/02/2015 06:51 PM, Roberto Fichera wrote:
>>>>>>> Overall, I don't see an obvious defect from you SSI side, but you
>>>>>>> may also try to toggle TDMAE and RDMAE at the point that callback
>>>>>>> stops -- re-raise the DMA requests by disabling and enabling TDMAE
>>>>>>> and RDMAE again and see if it works. I think either something did
>>>>>>> intervene register controls of SDMA or SSI,
>>>>> I will try this one.
>>> I will go over this tomorrow morning.
>>>
>> I've tried it just now but doesn't work at all! I'm getting only 2 sdma transfers.
> Heh, now I'm getting perhaps a similar issue -- transfers just stop
> for no good reason.
>
> I can use aplay all day long, and the transfers work great.  Even
> arecord + aplay together seem to work fine.
>
> However, when I use my portaudio based ramp checker, it runs from
> between 1 frame and several thousand, then the callbacks stop.  I
> don't know if this is a portaudio problem or an alsa problem -- i
> don't think I've seen the issue outside portaudio.
>
> Jackd seems to run okay too (I'm running an overnight full duplex test now).
>
> roberto, what user space library are you using?  Alsa directly, or
> portaudio, or something else? 

All is in kernel space, and as I've already said it's dahdi driver for a voip app.
The starting point I've used is fsl_ssi.c. I've removed most of the code not
related to TDM. Then I've added my dma support to move samples from TDM
to a dahdi audio sample buffer.
So it's supposed to be a very skinny TDM driver for SSI in normal and synch
mode.

> it looks like your data rate is quite
> manageable, right?  8kHz, 8 slots, 8 bits?  For me, it's a little
> better at 16kHz than 48kHz, but still just quits working after a
> while.

BCLK@2048KHz, FSYNC@8KHz, 32 slots at 8 bits but I'm masking all
except the first 2 I need.

> What's your experience of play vs. record, vs. full duplex?

Channels should be full duplex, and the samples has to go in dahdi buffer
finally used by asterisk as audio channel.

I'm currently thinking if would be better to write my driver as plain audio codec.
This means that I'll have to write my dahdi driver on top of either PCM or SND
framework, all within kernel space. But I guess this will over-complicate the things
compared to a straight TDM byte sequence, considering also that I'll have to
learn the sound API.

>
>
> -Caleb
>