The Rock Pi S has been in limbo for so long and received so many revisions it now gives more bad representation than sales at a guess.
Its such as shame as the S in being sound and audio had such great potential but for some reason the ADC decoupling caps where omitted on board.
Adding them after post gpio and not at Soc pin source is too late as all the board interference will be present and why they should be placed at pin source.
Likely it needs a rethink or maybe just EOL as the rk3308 wasnât the fastest either due to memory implementation and the reduced clock speeds.
I read baronets tweak but I wasnât sure that this is still valid after 3 years⌠I thought maybe todays software has been developed since then.
I am using Armbian_23.8.1_Rockpi-s_bookworm_current_6.1.50 from the Armbian download site.
Audio output from LINEOUT-pins works fine out-of-the-box!
My issue with audio input seems to be related to âpcm_hw_paramsâ according to the error-messages. So I was hoping to be a little more precise in what needs to be fixed here.
âDebianâ Features always worked better with stock kernels that never changes ⌠They also donât break as kernel never changes. I would assume OP wants to escape from Android kernel 4.4 or whatever stock version is but probably doesnât understand severity of the problem. Rare people do.
Development, porting and maintaining features on mainline kernel was covered almost entirely by Armbian developers private resources. This had to stop some time ago as there was absolutely no interest from anyone to compensate for the loss developers have by doing this. No budget development is extremely hard to drive.
But. The beauty of open source - you can easily download sources and start debugging on your own. Asking on forums can help you getting some tips, but finding people that really knows something valuable or that will waste weeks of their time for you is like winning a lottery. Armbian development tools will also save you some time.
HW vendors sale hardware with kernel that doesât change, so this support development is cheap and manageable.
You can try that and test, you could enable as did, the quality was poor.
The mics lines seem to pick up interference and always had a hunch the decoupling caps are ommitted.
They need to be as close to the SoC pins as at GPIO is a disaster.
I could be wrong, but the noise has that âcomputer interferenceâ tone. !?
Some years ago me and a friend bought a few RockPi-S boards, mainly because they were marketed with eight audio channels.
They have been collecting dust since the last time (2021) we tried to get the audio working properly.
We have since then been using Orange Pi Zero and Armbian for our audio purposes which works fine.
Now we wanted to give the RockPi-S boards a second chance. But the recommened kernel, tweaks and pinout is confusing to us. We have spent some hours this week reading the threds and testing to figure it out.
Most OS seems to handle audio output on pin LINEOUT-L and LINEOUT-R, as expected. The audio input is still a mystery to usâŚ
I totally understand the beauty of open source and the fact that this is a âdevelopment boardâ. It just that we are not that skilld, yet. So, obviously there is no quick-fix to get any current OS to harmonize with the RockPi S audio.
We have not yet looked into the debugging tools. That might be a âwinter challangeâ
Meanwhile we can still use the OPiZ or some other SBC for audio.
After installing rockpis_ubuntu_bionic_minimal_arm64_191219_0410-gpt.img
and applying baronets tweak I got these messages on de/re-compile:
root@rockpis:/boot/dtbs/4.4.143-34-rockchip-g3c9d2019dba7/rockchip# dtc -I dtb -O dts -f rockpi-s-linux.dtb -o rockpi-s-linux.dts
rockpi-s-linux.dts: Warning (unit_address_vs_reg): Node /ramoops_mem has a reg or ranges property, but no unit name
rockpi-s-linux.dts: Warning (unit_address_format): Node /reserved-memory/drm-logo@00000000 unit name should not have leading 0s
root@rockpis:/boot/dtbs/4.4.143-34-rockchip-g3c9d2019dba7/rockchip# dtc -I dts -O dtb -f rockpi-s-linux.dts -o rockpi-s-linux.dtb
rockpi-s-linux.dtb: Warning (unit_address_vs_reg): Node /ramoops_mem has a reg or ranges property, but no unit name
rockpi-s-linux.dtb: Warning (unit_address_format): Node /reserved-memory/drm-logo@00000000 unit name should not have leading 0s
Without the tweak applied I got sound out on pin LINEOUT-L and LINEOUT-R, as expected. (speaker-test -c2 -t sine -f 500)
With the tweak applied I got NO sound out on any pin, but maybe that has to do with those Warnings�
I think we can leave the sound quality issue for the moment and focus on the âaudio implementationâ.
The warnings are from a working DTB that you have merely converted from binary to text and back again and must be existing errors on other entities.
I seem to remember it was the same before also but we where on the 1st revision before Radxa even dropped 4mics from the the pin mux.
You could record from the mics before with the above, but like said sound quality binned that idea.
Apols its so long that I did give up, I am going to struggle to add anything I remember.
hi, i just follow your step, and can get the I2S MEMS microphone data, but then i changed I2S mems TO PDM MEMS microphone, i canât success, and the pin46(PDM_CLK_S_M2) has nothing signal, whatâs the problem ? please help , thanks a lot !
Features always worked better with stock kernels that never changes ⌠They also donât break as kernel never changes. I would assume OP wants to escape from 
