imx6q, issues i2s redirected to HDMI

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx6q, issues i2s redirected to HDMI

1,027 Views
angelo_d
Senior Contributor I

Hi all,

i have the need to play some audio coming from an i2s source (a radio fm) into hdmi card output.

i am using a simple alsa loop command as:

arecord --rate=48000 --device=sysdefault:CARD=imxaudiosi4745 -B 8000 -F 1000 | aplay --device=sysdefault:CARD=imxhdmisoc

And a simple hdmi CEA setup as below:

mxc_sdc_fb fb.28: 640x480 h_sync,r,l: 96,16,48  v_sync,l,u: 2,10,33 pixclock=25174000 Hz

On kernel 3.10.17 (from boundary) the loop plays fine for minutes.

On more recent kernel 3.14.28, i get some underrun messages here and there, after 10 to 40 seconds, and audio is interrupted from some small holes, or fully interrupted sometime.

arecord --rate=48000 --device=sysdefault:CARD=imxaudiosi4745 -B 8000 -F 1000 | aplay --device=sysdefault:CARD=imxhdmisoc

Recording WAVE 'stdin' : Unsigned 8 bit, Rate 48000 Hz, Mono

Playing WAVE 'stdin' : Unsigned 8 bit, Rate 48000 Hz, Mono

si4745-codec si4745-codec.355: si4745 codec, setting sample rate as 48000

overrun!!! (at least 0.044 ms long)

overrun!!! (at least 0.870 ms long)

overrun!!! (at least 0.011 ms long)

I don't see btw issues playing a wav file directly to hdmi, so it is like some issue in the i2s->hdmi conversion.

Was some similar issue knows ?

What do you suggest to do know (can't switch to other kernel versions now) ?

Many thanks

angelo

Labels (1)
0 Kudos
3 Replies

730 Views
angelo_d
Senior Contributor I

Hi Artur,

thanks, i solved with pulseaudio and module-loopback.

For other users, in case it is needed: this issue is nothing related to imx6q or kernels.

It is related to a common streaming issue of clock synchronizations between 2 sound cards / devices (live stream).

Even if the 2 devices suppose to use same sample clock, of course, clock is not exactly the same,

so one device is a bit faster, the other a bit slower.

Common way to solve this is to use larger buffers and allow intelligent software to correct the issue also in case inserting

frames or dropping them.

Regards,

angelo

0 Kudos

730 Views
art
NXP Employee
NXP Employee

Try to use a simple Gstreamer pipeline with I2S as a source and HDMI Audio as a sink.


Have a great day,
Artur

0 Kudos

730 Views
angelo_d
Senior Contributor I

Hi,

doing some progresses, the underrun issue happen with the following paths:

i2s (kernel) -> arecord (userspace) -> sound pipe (kernel) -> aplay (userspace) -> hdmi (kernel)

or

esai (kernel) -> arecord (userspace) -> sound pipe (kernel) -> aplay (userspace) -> hdmi (kernel)

So i excluded

1) i2s / esai drivers

2) hdmi driver, used pixelclock is the same of kernel 3.10, play fine from file, don't see issues here

so i concentrated in the middle part, how alsa "pipe" the samples, and found like the issue is in

the PCM/DMA part.

Backporting to 3.14.28 some 3.14.52 changes in sound/core/pcm_dmaengine.c is giving some improvements,

underrun is happening after some hours in 32000 and after several minutes at 44100 so i have at least some improvements.

regards,

angelo

0 Kudos