Hi,
Am 14.11.2018 um 13:45 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Peter,
Am 14.11.2018 um 12:06 schrieb Peter Ujfalusi peter.ujfalusi@ti.com:
Hi,
The defconfig for OMAP2+ now have the CPU_IDLE enabled which can cause audio artifacts because we try to enter too low power state from where the wakeup takes longer than the FIFO can tolerate on the dai side.
While adding pm_qos to McPDM and DMIC I have noticed that the McBSP calculation was not correct as we need usec for the latency value.
Regards, Peter
Peter Ujfalusi (3): ASoC: omap-mcbsp: Fix latency value calculation for pm_qos ASoC: omap-mcpdm: Add pm_qos handling to avoid under/overruns with CPU_IDLE ASoC: omap-dmic: Add pm_qos handling to avoid overruns with CPU_IDLE
sound/soc/omap/omap-dmic.c | 9 ++++++++ sound/soc/omap/omap-mcbsp.c | 6 +++--- sound/soc/omap/omap-mcpdm.c | 43 ++++++++++++++++++++++++++++++++++++- 3 files changed, 54 insertions(+), 4 deletions(-)
I will test asap.
I have now:
* v4.20-rc2 * plus your new patches * plus letux-4.20-rc2 patches * including our private AESS patch set (mostly inactive, because it fails to load firmware) * CONFIG_CPU_IDLE=y
and it works. I can use aplay and play to get handsfree audio as with CONFIG_CPU_IDLE=n
Sometimes, there is a scratchy tenth of a second (in handsfree and headset), but the basic rhythm does not get interrupted any more and the play command does not get stuck.
I have played an mp3 of 4 minutes and the play process did succeed and didn't report buffer underrun issues.
So your patches seem to fix the issue. At least the basic problems. This scratchy thing needs further study, if it is a spurious thing on my Pyra protoype device. Or if it is still there if we disable CPU_IDLE again (I haven't tried that yet).
BR and thanks for quick help, Nikolaus