Hi Fabio,
On Fri, Oct 11, 2013 at 11:01:29AM -0300, Fabio Estevam wrote:
Hi Markus,
[Also including alsa-devel and some other folks involved with mxs audio]
On Fri, Oct 11, 2013 at 9:12 AM, Markus Pargmann mpa@pengutronix.de wrote:
Hi,
v4 adds another patch to increase sound stability. Patch 3 ("dma: mxs-dma: Fix channel reset hardware bug") decreases the number of channel stalls, but after hours of repeated playback the bug still appears. The new patch ("dma: mxs: Use semaphores for cyclic DMA") replaces reset channel usage with hardware semaphore counter mechanism.
How is the bug you are trying to solve manifest and how to reproduce it?
My testcase is the following:
/bin/sh -c "while true; do ifconfig $net down; ifconfig $net up; done" & while $(timeout 10 aplay --period-size=160 --buffer-size=320 $audio_file); do ; done
$audio_file is a 1 second testfile: Signed 16 bit Little Endian, Rate 16000 Hz, Mono
The network interface up/down loop creates enough load that aplay is not able to deliver enough audio data into the DMA buffer resulting in many playback interruptions. The interruptions are triggered by the pcm_lib as soon as there is not enough data in the DMA buffer.
To stop the playback a DMA channel reset is executed. Sometimes this can lead to a channel stall. There is no audio playback possible until the next reboot or DMA engine reset. I fixed it by replacing channel reset with hardware semaphore counter.
The second issue was a sound quality problem. With one of those interruptions in playback, it was possible that the DMA buffer position pointer gets wrong due to missed interrupt calls. The result is a bad sound quality because the DMA engine is reading the same buffer segment as aplay is writing to. Fixed by using dma residue reporting.
I have been investigating an issue about sound stability on mx28 as well.
The usecase I am doing is:
while true do arecord -D hw:0,1 -d 10 -f S16_LE -r 44100 -c 2 | aplay sleep 2 done
(Record 10 seconds, sleep and keep in this loop forever).
The problem I see is that randomly the captured audio becomes extremely noisy and loud (throughout the whole 10 seconds) and then in the subsequent loop it becomes normal. This is very random and it happens at a 1 or 2% failure rate.
I tested your v3, but it did not help to fix this particular issue.
I think that is another problem independent of the other two issues I observed. You could try to remove the NO_RESIDUE flag from mxs-pcm which will enable the use of the residue reporting introduced in this series. But I don't think it will help.
I also tried experimenting with the SAIF IOMUX settings:
index cda19c8..463fa92 100644 --- a/arch/arm/boot/dts/imx28.dtsi +++ b/arch/arm/boot/dts/imx28.dtsi @@ -545,9 +545,9 @@ MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0 >;
fsl,drive-strength = <MXS_DRIVE_12mA>;
fsl,drive-strength = <MXS_DRIVE_4mA>; fsl,voltage = <MXS_VOLTAGE_HIGH>;
fsl,pull-up = <MXS_PULL_ENABLE>;
fsl,pull-up = <MXS_PULL_DISABLE>; }; saif0_pins_b: saif0@1 {@@ -557,9 +557,9 @@ MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0 >;
fsl,drive-strength = <MXS_DRIVE_12mA>;
fsl,drive-strength = <MXS_DRIVE_4mA>; fsl,voltage = <MXS_VOLTAGE_HIGH>;
fsl,pull-up = <MXS_PULL_ENABLE>;
fsl,pull-up = <MXS_PULL_DISABLE>; }; saif1_pins_a: saif1@0 {@@ -567,9 +567,9 @@ fsl,pinmux-ids = < MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0 >;
fsl,drive-strength = <MXS_DRIVE_12mA>;
fsl,drive-strength = <MXS_DRIVE_4mA>; fsl,voltage = <MXS_VOLTAGE_HIGH>;
fsl,pull-up = <MXS_PULL_ENABLE>;
fsl,pull-up = <MXS_PULL_DISABLE>; };and my tests are showing a much better stability. Not able to get this problem after several hours.
Regards,
Fabio Estevam
Regards,
Markus Pargmann