On 12/02/2016 10:23 AM, Peter Ujfalusi wrote:
@@ -637,12 +638,21 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp)
- Here we start the McBSP, by enabling transmitter, receiver or both.
- If no transmitter or receiver is active prior calling, then sample-rate
- generator and frame sync are started.
- Also setting of the QoS latency for the FIFO which varies upon the buffer
*/
- size. Approximately 2.3 milliseconds per FIFO location.
void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx) { int enable_srg = 0;
- int latency = mcbsp->pdata->buffer_size * 23;
I think this is not correct. The McBSP FIFO time depends on the sample rate and on the number of channels the audio is using. With 8KHz mono you have 12 times more time per FIFO element compared to 48KHz stereo.
As it has been discussed with Tony we should calculate the QoS latency in hw_params:
latency_ms = ((FIFOsize - FIFOthreshold) / channels) * 1000/sampling-rate
On OMAP3.McBSP2 for example (44.1KHz, stereo): FIFO threshold 128
- DMA request will be triggered when 128 slots are free in the FIFO
- at that point we have still 1152 words in the FIFO.
- if the C wakeup latency is longer then what it takes to play out the
samples from the FIFO (13.06ms), we will drain the FIFO and got underflow.
- in this case the QOS should be set as 13.06ms
FIFO threshold 1024
- DMA request will be triggered when 1024 slots are free in the FIFO
- at that point we have still 256 words in the FIFO.
- if the C wakeup latency is longer then what it takes to play out the
samples from the FIFO (2.9ms), we will drain the FIFO and got underflow.
- in this case the QOS should be 2.9ms
On other McBSPs with 128 word FIFO the required latency is shorter to ensure we don't drain the FIFO.
and we still have the issue of full duplex audio when the FIFO threshold is different for playback and capture...