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
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
Try to use a simple Gstreamer pipeline with I2S as a source and HDMI Audio as a sink.
Have a great day,
Artur
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