i.mx6 hdmi audio corruption

[pjdowner]

Hi,

We have developed a PVR application running on a quad core (i.mx6q), we use Yocto (fido branch) with the latest meta-fsl-arm from git. Our application isn't very cpu intensive but it does use several devices, it captures DVB-t video via PCIe, stores it on a hard disk and is later retrieved for playback. The playback is done using gstreamer, currently using playbin which selects the freescale beepdec for audio playback to an alsasink, we are not using pulseaudio, I have also experimented with different codecs without success with this problem.

If we stop the recording of data via PCIe, then already captured data will play without issue, so we do not believe that it is a HDMI issue or a codec issue. When our application is running as intended i.e. recording data and doing playback then the average CPU load is between 0.58 and 1.0 and the CPU usage is around 350% idle, so the CPU is not stressed other than with the number of interrupts which is around 1000/second.

The issue is that when the application is running and doing playback we will occasionally get hdmi audio corruption, but the video is fine. The corruption can sometimes resolve itself quickly or it can last for the whole playback of a file. We have been able to chase down the cause of the corruption to a link with the number of interrupts on the system, originally we were testing with a USB hard disk and when we installed and ran irqbalance which spread the interrupts across the CPUs the audio corruption disappeared. Unfortunately we want to ultimately use a SATA drive and when I switched to the SATA device realised that it generates far more interrupts than USB and the audio corruption returns even with irqbalance. I have been manually tuning the irqs and have tried putting the dma and IPU/VPU irqs on their own CPUs amongst other setups and can recuce the corruption but not get rid of it.

I would like to understand why the irqs are seemingly affecting the audio so badly and not the video, is this a buffer size issue and if so, where can the hardware audio buffer size be adjusted?

[igorpadykov]

Hi Philip

hdmi audio is handled in software by arm core in special way, described in

sect.16.2.5 Audio attached Linux Manual. As workaround one can try patches

for sdma on link below

Audio LOST after ~10 hrs on i.MX 6Q

Best regards

igor

[pjdowner]

Hi Igor, my apologies, I missed the notification for your reply.

I understand now that the audio is done in software on the i.mx6. I have been able to create audio buffer underruns and so I am confident that the issue itself is not an underrun as there are no error messages reported by gstreamer or the kernel and the underrun effect is different to the issue we are getting. Further to that, in situations where we do get underruns we can eliminate them by prioritising the process. We've been profiling the MMDC and cannot see any excessive utilisation or load there and changing the QoS settings also fails to improve the situation.

The issue can be easily replicated on several of our i.mx6 systems by writing out to a sata device at the same time that gstreamer playback is running, for example the following gstreamer command will do video playback but will replace the audio with a generated sine wave in order that the corruption is more obvious. The command which we run at the same time to cause the intermittent corruption is dd, the example below causes a much heavier test load which is around 56Mbps on our imx6 quad core whereas our application has an average load of 6Mbps to 8Mbps

gst-launch-1.0 filesrc location=video.avi typefind=true ! aiurdemux name=demux demux. ! queue max-size-buffers=0 max-size-time=0 ! vpudec ! imxv4l2sink demux. ! queue max-size-buffers=0 max-size-time=0 ! beepdec ! audioconvert ! 'audio/x-raw-int, channels=2' ! fakesink audiotestsrc ! audioconvert ! alsasink

dd if=/dev/zero of=/mnt/sda/testfile bs=512 count=10000000

I've been looking at the patches you linked to, but they're quite old and I think apply against 3.0.35, whereas we use 3.14.28, although I'm looking at porting them to 3.14.