[alsa-devel] fsl_ssi.c: Getting channel slips with fsl_ssi.c in TDM (network) mode.
Nicolin Chen
nicoleotsuka at gmail.com
Thu Oct 29 20:28:17 CET 2015
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.
More information about the Alsa-devel
mailing list