Cubox i4 Pro issues with HD audio (DTS-HD MA)

[banzapMember]

Hey,

I bought last week a new Yamaha sound bar, that supports basically all HD surrounds (TrueHD, DTS-HD/MA, etc).
I connected my 2-year-old Cubox i4Pro (with the last version of Geexbox end of April) to the soundbar and turned on the passthrough of HD audio (true HD and DTS HD).

When testing with an MKV movie with DTS-HD Master Audio track (5.1), I have audio drops each 15/30 seconds. I can confirm that is passing the right codec as the Yamaha soundbar tells me that is decoding DTS-HD MA.

– Does Geexbox/Cubox support passthrough of HD Audio?
– Hardware limitation or kernel/software limitation?

I even tried the fixed output configuration with 192 bitrate (same as HD audio), but also gives me drops in the sound. The only way to reproduce fine is downscale to DTS (uncheck the HD audio passthrough support).

Thanks for your help ?

[banzapMember]

Important info: is connected through HDMI.

[Warped RudiModerator]

Well, HD audio is somewhat sensitive on the iMX.6 hardware. Are you playing your video via wired network? If so, try to restrict the speed to 100MB using ethtool. Or rule this out completely by using WLAN or local storage. Also take a look here. Your problem might be related to interrupt latency as well. So inspecting the irq distribution any maybe playing with the affinities might be worth a try. And finally, set Kodi to change the refresh rate to match the video.

I have only one longer test video with DTS-MA here. But was able to play it (something like 90 min) with only one or two hiccups. This was on a Hummingboard i2ex that loaded the stream via an USB WLAN-adapter from an DLNA server and played it to my Yamaha AVR. So in principle it should work.

[banzapMember]

I’m playing directly from an HD disk connected to the Cubox (through a powered USB hub, in NTFS).

Will take a look at the link about the latency/irq.

Regarding the Kodi refresh rate, I have configured to set the video out refresh rate to match the video (if is 24p, set the TV to 24p). Is this what you mean? and/or there are other options that I need to change?

For info, my sound bar is a Yamaha YSP-2500.

Also, is there anything that I can debug on geexbox/kodi to see what is happening? Looking to the normal logs, there is no main error apart from this one: ERROR: CAESinkALSA – snd_pcm_writei(-32) Broken pipe – trying to recover

Thanks

[banzapMember]

Ok, I took a look in the other thread (about IRQ).
I really don’t know a lot about IRQ, I did some reading and tried to look to the interrupts and irqbalance man.

I did some changes in the ethernet connection, if I set to 100mpbs, doesn’t solve the problem. However, if I disable (ifconfig eth0 down) the ethernet, almost no interruptions in the HD audio. I really think that is something related to interrupts/irq, as you said.

Based on this, can you give me some hints on what should I look for in the interrupts/irq?

Thanks

[Warped RudiModerator]

I re-tested the movie yesterday for about 45 minutes on a Cubox-i4pro connected to a 100MB switch and DTS-MA was rock solid. Without even a single glitch. AVR is an Yamaha RX-A810, which is known to be very forgiving when it comes to out-of-spec input signalling…

I’m playing directly from an HD disk connected to the Cubox (through a powered USB hub, in NTFS).

I’m wondering if this has an impact. I’m not directly a fan of NTFS in Linux and the hub might have an influence as well.

I have configured to set the video out refresh rate to match the video (if is 24p, set the TV to 24p). Is this what you mean?

Yes.

Based on this, can you give me some hints on what should I look for in the interrupts/irq?

Well, the idea would be to let the USB and network interrupts to be handled by a different core than the audio/video interrupts. But this is a somewhat hackish approach. The best would be it we could reproduce the issue and see what can be done on the kernel side…

Edit: Just after writing this, I remembered that I have an ext4 formatted USB drive laying around here. I connected it directly and did indeed observe a few drop-outs. Looking at the interrupt stuff, you might want to try the following:

systemctl disable irqbalance
echo e > /proc/irq/71/smp_affinity
echo e > /proc/irq/72/smp_affinity
echo e > /proc/irq/75/smp_affinity
echo e > /proc/irq/150/smp_affinity
echo e > /proc/irq/151/smp_affinity

This will cause the USB, Ethernet and SATA interrupts to be handled by core 1 instead of core 0. Let’s see if it has any effect.

[banzapMember]

@Warped Rudi
Thank you for your help!

Changing the IRQ balance did the trick. However, was not sufficient all of those resources. I took a look also to the /proc/interrupts table to see what other resources were interrupting in the CPU0. Decided to move the ones in 41-44 (related to galcore) to the CPU3/4.

echo c > /proc/irq/41/smp_affinity
echo c > /proc/irq/42/smp_affinity
echo c > /proc/irq/43/smp_affinity
echo c > /proc/irq/44/smp_affinity

I can reproduce now well, without any cuts in the audio ?

Thank you and hope that this post could help others.

EDIT:
Still found some cuts, moved 44 to CPU4 only:

echo c > /proc/irq/44/smp_affinity

[Warped RudiModerator]

Could it be you mean: echo 8 > /proc/irq/44/smp_affinity ?
But anyway, we see the problem. Obviously our irqblance tool doesn’t work correctly and the audio driver appears to be very sensitive to latency issues when high bitrate streams are transmitted. Let’s see if we can do something about this…

[banzapMember]

Yes, that’s what I meant.

Here is my final affinity config:

#eth0
echo e > /proc/irq/150/smp_affinity
echo e > /proc/irq/151/smp_affinity
#USB disk
echo 8 > /proc/irq/71/smp_affinity
echo 8 > /proc/irq/72/smp_affinity
echo 8 > /proc/irq/75/smp_affinity
#others with interrupts du
echo c > /proc/irq/41/smp_affinity
echo c > /proc/irq/42/smp_affinity
echo c > /proc/irq/43/smp_affinity
echo e > /proc/irq/44/smp_affinity

But I do still get drops sometimes (trying to debug the bitrate and I think is when goes above 6Mb/s for some time, reading from disk or buffering? dunno tbh).

Thanks ?

[banzapMember]

Hi Warped Rudi,

After a lot of work around and reading some forums about low-latency config for Linux kernels, IRQ, PCI BUS, etc; did some changes that will put here:

This is my interrupt configuration (not sure if makes sense as some were kind of random changes based on the interrupt count, but is working):

# USB-HHD/SDCARD/Ethernet => CPU1
echo e > /proc/irq/71/smp_affinity
echo e > /proc/irq/72/smp_affinity
echo e > /proc/irq/75/smp_affinity
echo e > /proc/irq/150/smp_affinity
echo e > /proc/irq/151/smp_affinity
echo e > /proc/irq/147/smp_affinity
echo e > /proc/irq/54/smp_affinity
echo e > /proc/irq/55/smp_affinity
# VIDEO => CPU2
echo c > /proc/irq/34/smp_affinity
echo c > /proc/irq/42/smp_affinity
echo c > /proc/irq/44/smp_affinity
# VIDEO => CPU3
echo 8 > /proc/irq/38/smp_affinity
echo 8 > /proc/irq/41/smp_affinity

Increase real-time clock (RTC) frequency:

echo 3072 >/sys/class/rtc/rtc0/max_user_freq

Change CPU scaling governor to performance (always max freq). more energy consumption and temperature?

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

TBH, I think the CPU governor did the trick as I looked a lot to the CPU/system load using htop command and tracked a lot of high CPU usage when there were sound drops. Maybe later I will try putting back the IRQ balancer but for now, will leave like this.

Thanks ?

[banzapMember]

To note that irqbalance is disabled and this configuration runs as a script in the system startup (through systemd).

[Author]

Posts