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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
