xrun issue while reading audio data from 8MIC-RPI-MX8 and alsa loopback sound card

[nsoni]

Hello, I am using imx8m-plus EVK kit along with 8MIC-RPI-MX8 mic board attached to it. I am trying to read 8-mic data from mic board along and 1ch from alsa loopback sound card to be used as aec reference signal (which is coming from PJSIP voip client app running separately). I am getting periodically xrun issue in the application which is reading this audio samples. It seems clocks are not synchronized between mic board and alsa loopback sound card. Looking for help to debug and fix this issue.

[juangutierrez]

Hi nsoni

We provided the information on how to reproduce the issue with the SW team, but we have not received any response yet. Let me investigate about the ASRC then. I am trying to see internally who can help us with this. Thanks for your patience.

-juan

[nsoni]

Hi @juangutierrez 

Thanks for your support. Please keep us updated on XRUN and ASRC progress. As discussed previously as well, we see the noise in arecord file (once in 10 or 15 minutes) in latest/previous AFE code. I am not sure if this is related to XRUN or separate issue. But this is easy to notice on recorded file. 

I have attached noise captured at my side. Please check if you also see it and is it related to xrun issue or it's a separate issue which needs to be debugged as well. Thanks.

[juangutierrez]

Sorry, I have not fully understand where the ASRC will be placed . Would you post a block diagram or something that depict the use of the ASRC on your system, please?

[nsoni]

Hi @juangutierrez 

It was just a suggestion that if use of ASRC can help to address this xrun issue we see on AFE code. Even I don't have enough details as of now to put the block diagram and not sure how ASRC can be used in such case. If you can discuss with ASRC expert, we can know more.

Anyways, currently we see issue once in 30 minutes after that it recovers the sound card which will result in the audio glitch. This can be issue for customer who wants to pass any certification for VOIP.  Is your team still looking into the XRUN issue to fix it without recovering from it? Also let us know if you know the reason why we are getting XRUN on first place ? Is it clock sync issue between SAI ports or something else?

[juangutierrez]

Hi nsoni

ASRC might be a good option, but as far as I am aware this is only supported on the 8MPlus through the hw:wm8960audio,1.

So, yes, I think you can try modifying the asound.conf to use this subdevice

pcm.spk
{
type plug
slave.pcm "hw:wm8960audio,1"
}

With latest AFE provided by Ohtokani, we are still seeing the XRUNs but the system is able to recover. I mean considering Linux is not an RTOS, is this an acceptable behavior or not? 

Have you tried scaling the governor to performance to see if that helps with the issue?

echo "performance" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

[nsoni]

Hi @juangutierrez,

Yes, with latest AFE code, sound card does recover and we see very less XRUN (once in around 30 minutes) with latest AFE code and governor set to performance mode. But the issue is not yet fixed completely. 

Regarding ASRC, we are already using hw:wm8960audio,1 (HiFi-ASRC-FE) for speaker but this is not helping. It seems HiFi-ASRC-FE sound card provides ASRC support for capture/playback stream from/to wm8960 codec only (as per Section 7.2.2.2 in i.MX_Reference_Manual.pdf).

While in AFE code (which is similar to our application for VOIP), we use SAI5 for PDM data, SAI3 for wm8960 and alsa-loopback for send/receive data to/from aplay and arecord. So I think this will need custom changes for enable ASRC for such usecase. But we are not sure how to enable ASRC for such scenario. Let me know what you think and correct me if I am wrong. 

[nsoni]

Hi @juangutierrez & @Ohtokani_Pinzón 

I noticed the last binaries and source code uses 240 period size with 16K rate (which is 15ms block size). What we are looking for is 5ms block size which can be achieved with either setting (240 period size, 48K) or (80 period size, 16K). 

So when I tried to change 16K to 48K rate (keeping period size as 240), this gives xrun issue with latest code. I noticed the xrun messages not enabled in latest code which I had enabled as well. So we are still dealing with same issue which was originally reported (xrun at 240bs, 48K). Can you please check again? I guess we may need to use HW asrc to fix this issue.

[Ohtokani_Pinzón]

Hi nsoni

I tried with another internal version of the afe, and it seems to work fine.

I tried to enable the xrun messages on this code but the AudioStream files differ a lot from the previous versions, and I'm not sure where to place the messages.

However I tested the afe playing music and recording at the same time and it souds well.

I'm using these lines to test:

1.   modprobe snd-aloop

2.   ./afe libdummy & 

3.   aplay audio-sample.wav -c2 -r48000 -fS32_LE &

4.   arecord -d10 -fS32_LE -r48000 -c1 audio-sample-2.wav

Let us know if it works well on your side.

[nsoni]

Hi @Ohtokani_Pinzón ,

Though the issue is not seen too frequently like earlier, I can still reproduce it. In wav file recorded with arecord command, I can hear the crackling noise (mostly due to overrun) at few minutes interval (around 11min to 12 min). aplay also reports underrun as attached in the log. And I also put xrun message in the latest code (attached the patch) and I can see it being printed at some intervals. So the issue is still present but with lesser frequency.

Do you think we need to use HW ASRC block which will synchronize all SAI interfaces?

[Ohtokani_Pinzón]

Hi nsoni

We haven't found the bug yet, but the software team is also helping us to solve the issue.

Can you please tell us how are you planning to use the ASRC?

[nsoni]

Hi Ohtokani,

You can reproduce the issue either listening to recorded file (atleast record for 30 minutes and listen to file for audio drops) or by enabling the XRUN messages (atleast run for 30 minutes) as per patch I attached in previous thread.

Regarding ASRC, Is there a way to enable ASRC which can synchronize the SAI interfaces audio data (SAI5 of mic and SAI3 for codec) along with alsa loop-back sound card ?

[Ohtokani_Pinzón]

Hi nsoni

Ok, let me check if I see the same problem and look for the cause

[nsoni]

Hi @juangutierrez & @Ohtokani,

If I use afe binary shared by Ohtokani, I don't see the xrun messages, however music seems to start getting interrupted in few minutes which seems to be xrun issue to me. Can you confirm if xrun messages is enabled and music is also good with the afe binary shared with us ?

If I build afe with patch given by Ohtokani, I see XRUN messages are enabled in the patch and I also get the error in few minutes when I used locally built afe binary with the patch.

[Ohtokani_Pinzón]

Hi nsoni

the afe binary I shared has enabled the xrun messages, I had only tested the afe without playing music or recording. Let me test it and see if it works.

[Ohtokani_Pinzón]

Hi nsoni

Yes there was a problem with the binaries generated by the patch, The xrun problem was still happening even though the xrun message didn't appear.

But with this version of the afe it seems to work fine with a period size of 240.

Let us know if it also works on your side.

[nsoni]

Hi Ohtokani,

I am running this binaries for last 30 minutes along with music playback and capture and seems to be fine. Any idea what is making difference here compared to previous versions of afe repo ?

I see below differences in this latest release. Let us know if you know what is the fix here.

1) asound.conf : "hw:wm8524audio,0" is replaced with "hw:wm8960audio,1".  The device 1 represents ASRC (HiFi-ASRC-FE) which may be making difference.

2) asound.conf : pcm.mix (buffer_size 2048, period_size 512) is now replaced with (buffer_size 4096, period_size 1024).

3) Change in AudioStream code

I will build the binary myself now and verify once more. If that works, we can mark it closed. Thanks @Ohtokani_Pinzón & @juangutierrez  for the support

[juangutierrez]

Hi nsoni

My guess is the issue is fixed on the Changes in AudioStream code.

Ohtokani is testing with 8MM so no ASCR involved there.

The buffer size is not a multiple of 240 so I dont think affects too, but you can try it changing it and see if that helps.

We will try to narrow down to see if we can provide a patch for the latest nxp-afe.

[juangutierrez]

@Ohtokani_Pinzón  can confirm but with the latest patch he shared you should be able to build both afe and libdummy.so library.

Actually most of the changes are indeed for the afe.

[juangutierrez]

Hi nsoni

Would you try with the binaries shared by Ohtokani and the asound.conf

Place the asound.conf at /etc/ directory.

We no longer see the xruns with those binaries.

which linux version are you using, do you have any other modification?

[nsoni]

HI juangutierrez,

I compared binaries shared by Ohtokani and libdummyimpl.so/libdummyimpl.so.1.0 are same. I used afe binary from Ohtokani and with that it's running for last 30 minutes without any xrun. I hope XRUN message is enabled in the binary. If so, Can you please share the afe source code with me?

There is slight different in asound conf as well but that is in codec part as below.

From Ohtokani :

pcm.spk
{
type plug
slave.pcm "hw:wm8524audio,0"
}

From nsoni :

pcm.spk
{
type plug
slave.pcm "hw:wm8960audio,0"
}

It seems codec is different on our board. I am using imx8m+plus EVK lpddr4 kit by the way. Anyways, I kept mine only during the experiment.