PulseAudio / gstreamer not working with I2S microphone connected to Rubik Pi

@kinkin I tried doing a fresh build and the outcome was the same as before. Here are the exact steps taken:

mkdir rubikpi
cd rubikpi
repo init -u https://github.com/rubikpi-ai/rubikpi-manifest -b qcom-linux-scarthgap -m rubikpi-6.6.97-QLI.1.6-Ver.1.3_qim-product-sdk-2.1.1.xml
repo sync
repo forall -j4 -c "git lfs pull"

Could you please verify the manifest used above is the correct one? It is the latest (QLI 1.6).
Note that the gflags repo changed the name of its master branch to main, so i had to fix that:

 nano layers/meta-openembedded/meta-oe/recipes-support/gflags/gflags_2.2.2.bb

I then applied the two patches, and no errors were reported (rc = 0)

buildbox@buildbox:~/rubikpi$ cd ~/rubikpi/src/vendor/qcom/opensource/kernel-6.6
patch -p1 < ~/0001-audio-40-pin-enable-1CS43434-1-2.patch.txt
patching file arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dtsi

buildbox@buildbox:~/rubikpi/layers/meta-rubikpi-bsp$ cd ~/rubikpi/layers/meta-rubikpi-bsp
patch -p1 < ~/0002-audio-40-pin-enable-1CS43434-2-2.patch.txt
patching file recipes-multimedia/audio/agm/0009-change-the-capture-format-of-ICS43434.patch
patching file recipes-multimedia/audio/pal/0007-modify-the-backend-of-handset-mic.patch
patching file recipes-multimedia/audio/qcom-acdbdata_git.bb
patching file recipes-multimedia/audio/qcom-agm_git.bb
patching file recipes-multimedia/audio/qcom-pal_git.bb
patching file recipes-multimedia/audio/qcom-pw-pal-plugin/0002-add-handset-mic-configuration-for-ICS43434.patch
patching file recipes-multimedia/audio/qcom-pw-pal-plugin_git.bb

I then run the build, which succeeds:

./rubikpi_build.sh
./rubikpi_build.sh --zip_flat_build

I flash the image as normal using QDL, and i get the same errors as in my earlier post:

Thank you for your response. We will sync this internally and get back to you as soon as possible.

Thanks @kinkin i’d really appreciate this as we have several customers who are desperate for this to be fixed

Hi @kinkin,

Just following up — it’s been 10 days and our customers are still affected. Any update or rough timeline would be greatly appreciated.

Thank you!

Our R&D team is currently debugging this issue. We expect to have an update within this week or next week. Thank you for your patience.

This is probably not the issue but I looked at the logs and was wondering if the DSP’s started. One way to confirm:

 sudo dmesg | fgrep Booting
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[   14.782028] remoteproc remoteproc0: Booting fw image qcom/qcs6490/adsp.mdt, size 6852
[   15.267664] remoteproc remoteproc3: Booting fw image qcom/qcs6490/cdsp.mdt, size 5252

Then:

cat /sys/class/remoteproc/remoteproc[03]/state
running
running

@sidneym Thanks for the suggestion. I tried on both the working and non-functional builds and the output is the same in both cases:

root@rubikpi:~# sudo dmesg | fgrep Booting
fgrep: warning: fgrep is obsolescent; using grep -F
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[    5.068619] remoteproc remoteproc2: Booting fw image qcom/qcs6490/adsp.mdt, size 6852
[    5.102888] remoteproc remoteproc3: Booting fw image qcom/qcs6490/cdsp.mdt, size 5252
root@rubikpi:~# cat /sys/class/remoteproc/remoteproc[03]/state
offline
running

@kinkin It’s been another 2 weeks. All we need is a way to reproduce the working build from Feb 9th. Rather than the patch which doesn’t work, could you please commit the changes to a branch in the two repos and share them via github?

@amccem, The output you showed implies that remoteproc0, which I think is the ADSP, never fully booted:

cat /sys/class/remoteproc/remoteproc[03]/state
offline
running

We have updated the patch and verified that it works.
Please use repo sync to update your codebase, apply the patch we provided earlier, and test again.

It’s working, thanks very much @kinkin !

Great! thank you for your reply.