From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Matt Ranostay <matt@ranostay.consulting>,
linux-omap@vger.kernel.org, alsa-devel@alsa-project.org
Cc: Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH v3] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
Date: Fri, 2 Dec 2016 10:26:06 +0200 [thread overview]
Message-ID: <99749615-11be-0e24-0b46-f43112e08574@ti.com> (raw)
In-Reply-To: <e8e9a552-14d9-15eb-bf9a-48fdc79965e2@ti.com>
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
next prev parent reply other threads:[~2016-12-02 8:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1480555145-8300-1-git-send-email-matt@ranostay.consulting>
2016-12-02 8:23 ` [PATCH v3] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Peter Ujfalusi
2016-12-02 8:26 ` Peter Ujfalusi [this message]
2016-12-04 1:33 ` Matt Ranostay
2016-12-05 9:35 ` Peter Ujfalusi
2016-12-05 15:30 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99749615-11be-0e24-0b46-f43112e08574@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-omap@vger.kernel.org \
--cc=matt@ranostay.consulting \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox