topic Re: kernel 3.14, audio clocks and sample rates issues in i.MX Processors

kernel 3.14, audio clocks and sample rates issues

angelo_d — Wed, 19 Aug 2015 07:55:37 GMT

Hi all,

i moved from kernel 3.10 to 3.14 in a very similar sabre-auto board.

With this kernel I am having some new issues when i redirect audio from radio chip (silabs si4745, 32Khz master clock) to the cs42888 output codec.

Mainly,

- pulseaudio: sinks don't like 44100 as default-sample-rate, while audio is good at 48000Hz.

- alsa tests, similar issues:

arecord --device=default:CARD=imxaudiosi4745 | aplay --device=default:CARD=cs42888audio (8khz sample rate, OK, GOOD)

arecord -r 48000 --device=default:CARD=imxaudiosi4745 | aplay --device=default:CARD=cs42888audio OK, GOOD

arecord -r 44100 --device=default:CARD=imxaudiosi4745 | aplay --device=default:CARD=cs42888audio

overrun!!! (at least 12.157 ms long)

Also, when i use alsa and set as output the HDMI (FM radio to HDMI), i get continuosly "underrun" messages and audio cuts. In this case, using pulseaudio gives a good quality, but audio is delayed of some seconds, probably used from pulseaudio as a buffer to avoid underrun.

Something seems connected to the FM radio master clock, like seems multiples of 8Khz works fine (FM chip uses 32768 master clock).

What i miss actually is:

- sample rate: it is decided from the sampling source. Why must be set in the output device and it don't adapt automatically to the source sample rate ?

In kernel 3.14 device tree there are new &clk {} entries to be set (i copied them , from sabreauto), and this make me suspect it is connected to the issue i am having.

Every light on this is welcome.

Thanks & Best regards

Re: kernel 3.14, audio clocks and sample rates issues

jimmychan — Tue, 01 Sep 2015 05:23:39 GMT

Do you mean everything is working well in 3.10 but not in 3.14?

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Tue, 01 Sep 2015 16:19:21 GMT

Yes, looks like.

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Wed, 02 Sep 2015 13:27:41 GMT

I just verified this command in 3.10

arecord -fdat --device=sysdefault:CARD=imxaudiosi4745 | aplay -fdat \
--device=sysdefault:CARD=imxhdmisoc
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
overrun!!! (at least 0.047 ms long)
overrun!!! (at least 0.254 ms long)
overrun!!! (at least 0.027 ms long)

Overrun was happening on 3.10 also, but was happening after 5 minutes and seems to give very minimal audio cut, so likely, imho, it is acceptable.

On 3.14 overrun happen in some seconds and audio cuts are well audible, each about 10 secs (overrun warnings interval).

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Thu, 03 Sep 2015 10:39:22 GMT

Hi,

i am back on this issue, did more tests:

1) redirecting cs42888 line input to hdmi gives exact same issue:

# arecord --device=sysdefault:CARD=cs42888audio | aplay --device=sysdefault:CARD=imxhdmisoc

Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Channels 4

Playing WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Channels 4

underrun!!! (at least 6099.434 ms long)

underrun!!! (at least 8024.951 ms long)

underrun!!! (at least 8024.919 ms long)

underrun!!! (at least 7074.981 ms long)

underrun!!! (at least 8024.999 ms long)

underrun!!! (at least 8024.920 ms long)

underrun!!! (at least 8024.674 ms long)

underrun!!! (at least 7075.239 ms long)

underrun!!! (at least 8024.987 ms long)

2) the only good audio played to hdmi is when i "aplay" from file to hdmi.

Shouldn't be the ASRC stage of the imx6 able to take care of eventual samplerate differences ?

Or, is possible issues are in the target hdmi device someway too fast ?

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Fri, 04 Sep 2015 13:07:21 GMT

I enabled alsa xrun debug,

and at each underrun recording from cs42888 and playing to hdmi i see:

[16781.058145] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/339456/339456/337920
[16781.058334] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/339456/339456/337920
[16781.058524] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/339456/339456/337920
[16781.058710] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/339456/339456/337920
[16781.060460] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=2304/768/6144, hwptr=768/339456/340224/337920
[16781.084090] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=3072/768/6144, hwptr=768/340224/340992/337920
[16781.107713] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=3840/768/6144, hwptr=768/340992/341760/337920
[16781.131336] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=4608/768/6144, hwptr=768/341760/342528/337920
[16781.154965] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=5376/768/6144, hwptr=768/342528/343296/337920
[16781.178592] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=0/768/6144, hwptr=768/343296/344064/337920
[16781.178632] ALSA sound/core/pcm_lib.c:177 XRUN: pcmC1D0p:0
[16781.178652] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.28-gd3092ec-dirty #155
[16781.184887] [<80014c38>] (unwind_backtrace) from [<80010fb8>] (show_stack+0x10/0x14)
[16781.191369] [<80010fb8>] (show_stack) from [<8054fe10>] (dump_stack+0x7c/0xbc)
[16781.197328] [<8054fe10>] (dump_stack) from [<80400f74>] (xrun+0x88/0xb0)
[16781.202753] [<80400f74>] (xrun) from [<80401a94>] (snd_pcm_update_state+0xf8/0x100)
[16781.209130] [<80401a94>] (snd_pcm_update_state) from [<80401cc4>] (snd_pcm_update_hw_ptr0+0x228/0x834)
[16781.217155] [<80401cc4>] (snd_pcm_update_hw_ptr0) from [<8040238c>] (snd_pcm_period_elapsed+0xbc/0xf4)
[16781.225183] [<8040238c>] (snd_pcm_period_elapsed) from [<8042122c>] (hdmi_sdma_callback+0x88/0x98)
[16781.232864] [<8042122c>] (hdmi_sdma_callback) from [<80252264>] (sdma_tasklet+0x58/0x100)
[16781.239761] [<80252264>] (sdma_tasklet) from [<8002bfe4>] (tasklet_action+0x78/0x110)
[16781.246310] [<8002bfe4>] (tasklet_action) from [<8002c1d0>] (__do_softirq+0x10c/0x248)
[16781.252945] [<8002c1d0>] (__do_softirq) from [<8002c594>] (irq_exit+0xb8/0xf4)
[16781.258888] [<8002c594>] (irq_exit) from [<8000eb80>] (handle_IRQ+0x44/0x90)
[16781.264658] [<8000eb80>] (handle_IRQ) from [<800084f8>] (gic_handle_irq+0x2c/0x5c)
[16781.270950] [<800084f8>] (gic_handle_irq) from [<80011ac0>] (__irq_svc+0x40/0x70)
[16781.277141] Exception stack(0x807d3f18 to 0x807d3f60)
[16781.280904] 3f00:                                                      807d3f60 0000418c
[16781.287801] 3f20: 28cebd57 00000f43 276e4ac7 00000f43 bf7c4df8 807defe4 00000001 bf7c4dfc
[16781.294696] 3f40: 807d2000 807d2000 00000017 807d3f60 8006ea68 8036a288 60010013 ffffffff
[16781.301600] [<80011ac0>] (__irq_svc) from [<8036a288>] (cpuidle_enter_state+0x50/0xe0)
[16781.308238] [<8036a288>] (cpuidle_enter_state) from [<8036a410>] (cpuidle_idle_call+0xf8/0x148)
[16781.315657] [<8036a410>] (cpuidle_idle_call) from [<8000ed1c>] (arch_cpu_idle+0x8/0x44)
[16781.322384] [<8000ed1c>] (arch_cpu_idle) from [<80063f84>] (cpu_startup_entry+0x104/0x150)
[16781.329371] [<80063f84>] (cpu_startup_entry) from [<80797a94>] (start_kernel+0x2ec/0x2f8)
[16781.344514] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=0/768/6144, hwptr=0/0/0/0
[16781.366357] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=768/768/6144, hwptr=768/0/768/0
[16781.366547] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=768/768/6144, hwptr=0/768/768/0
[16781.366594] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=768/768/6144, hwptr=0/768/768/0
[16781.366798] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=768/768/6144, hwptr=0/768/768/0
[16781.389986] ALSA sound/core/pcm_lib.c:407 period_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=768/768/1536/0
[16781.390188] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/1536/1536/0
[16781.390234] ALSA sound/core/pcm_lib.c:407 hwptr_update: pcmC1D0p:0: pos=1536/768/6144, hwptr=0/1536/1536/0

Maybe you seee something useful.

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Tue, 08 Sep 2015 13:22:03 GMT

Hi all,

still an update:

When i connect the small hdmi TV XTL-1008HD, i get this available modes from userspace:

bash-3.2# cat /sys/class/graphics/fb2/modes

S:640x480p-60

S:720x480p-60

S:720x576p-50

S:1280x720p-50

S:1280x720p-60

S:1920x1080p-24

S:1920x1080p-50

S:1920x1080p-60

V:640x480p-60

U:1280x800p-60

V:640x480p-60

bash-3.2#

Seems like the only format where audio is played correctly (no overrun) is :

video=mxcfb3:hdmi,640x480M@60,if=RGB24

Also, i see that in some cases, if a wrong resolution is set, like 1280x800@60 that seems unsupported from the monitor, audio is played faster with immediate underrun.

So issues seems due to a non correct hdmi target speed due to the initial synch.

Another idea is that maybe this small cheap TV is not so good for hdmi audio player.

Re: kernel 3.14, audio clocks and sample rates issues

angelo_d — Tue, 24 May 2016 13:41:50 GMT

Hi,

in case someone could need it, i post the solution

imx6q, issues i2s redirected to HDMI