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...
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
