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.