Re: fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.

[Nicolin Chen <nicoleotsuka@gmail.com>]

On Thu, Oct 29, 2015 at 12:06:16PM -0700, Caleb Crome wrote:

> This actually is exactly what I'm seeing now.  I'm seeing the
> *startup* happening from the trigger starting up slipped.  So this
> does make perfect sense to me.

I saw your problem in the other reply. And I suggested you to let
DMA work first before SSI gets enabled. As SDMA in that case would
transfer one burst length (16 if you applied my patch I sent you)
and pause before SSI gets enabled. Then SSI would have enough data
to send out without any startup issue.

> It occurred to me that perhaps the problem has to do when exactly when
> during the frame-sync period the fsl_ssi_trigger function was called.
> Perhaps, if it's called near the end or beginning of a frame, somehow

I don't know how you measured if it's before of after. But the frame
should not start until trigger() gets call -- more clearly SSIEN and
TE get enabled. From my point of view, you problem should be caused
by SSI getting enabled without enough data in the FIFO. And that's
what I just described in the previous paragraph and previous reply.

> something gets messed up.  (The docs for the SCR register imply some
> of this, but it talks about either 2 or 6 bit clocks, so I'd expect
> the error rate to be lower than 7% (more like 2.5%).

> In addition, I have run about 20 minutes of audio with no slips or
> problems, even though there have been aplay underruns.  This is a
> major step forward for me :-)

It'd be better to avoid user space ALSA underun as it may skip some
data.