Orange Pi 3B with PCM5122 works together

Community Tutorials
21

I would still like to understand how it works: aplay -l takes the simple-audio-card,name for the only sound card it shows from the sound node. It would usually take that as hint, that the sound node, which refers to the 3.5mm jack, was probed, which is not what we want.

If both compatible = "simple-audio-card"; were probed, I would usually expect two sound cards in aplay -l.

If you change simple-audio-card,name in my-soundcard, does this have an effect on the name shown in aplay -l. And if you status = "disabled" the sound node, is aplay -l not showing any sound card anymore?

That both compatible = "simple-audio-card"; would get somehow merged into one usable ALSA device does not seem logic to me, or if at all, more by accident than intentional, hence fragile. I’d usually expect a clean overlay to either only create a new node, which appears as additional ALSA device, or disable or replace (adjust properties as needed) an existing node, if it conflicts. But changing only the simple-audio-card,name of one node + adding an entirely new one both, does not seem correct/clean, as far as I understand how these work.

EDIT: One thing I understood in the meantime, is that nodes are enabled by default, which is why the sound node does not contain a status = "okay" property. Hence that is not needed for the my-soundcard node either (but does not hurt). status = "okay" is only needed, if a node is defined with status = "disabled" in a dtsi, and you want to enable it in a board dts.This also means that status = "disabled" works on the sound node, to really disable onboard audio. If the PCM5122 is afterwards not detected, I’d assume something to be wrong in the my-soundcard node.

22

Re @MichaIng

Actually, during my tests, having different names for the my-soundcard section and the sound section caused a malfunction;
I even tried completely deleting the `sound` node and rewriting it, but that caused a crash.
The only working method is to use the original node and rewrite the specific parts I need, because the sub-nodes have quite complex branching structures. Just a reminder: I’m not a programmer, and this tree structure is confusing for me too. As I understand it, creating a custom overlay merges the two files, but the order in which they are applied is crucial to the final result.

Again, it works almost miraculously—I haven’t fully grasped how I managed it myself—but as far as I can tell, I added a layer that adapts the operation to my needs (or rather, to the PCM5122’s requirements).
Since there’s almost no information or documented success regarding this setup, I’m mostly proceeding by trial and error. Here, with the RK3566, we’re limited to 16-bit audio to find a common clock between the PCM5122 and the RK3566.

With the H618, which is more flexible, I hope to handle 32-bit audio. In any case, off-the-shelf boards using only pins 3, 5, 12, 35, and 40 don’t support the MCLK pin, so we’re forced to rely on the PCM5122’s internal PLL. Raspberry Pi chips might be better off in this regard; otherwise, we’re stuck with standard 16-bit/44.1kHz CD-quality audio at the ALSA level—anything else is just oversampling, given the lack of a physical MCLK pin connection.

So, to get back to the main point: within the overlay, the my-soundcard section creates an audio node tailored to the PCM5122, while the sound section lets me name it whatever I want so I can identify it via the command line. I’ve run aplay -l, understanding that I’m routing through the RK817 in 16-bit, 44.1 kHz stereo Hi-Fi mode—a setting that is hard-coded and prioritized in the RK3566’s factory-level device tree structure.

That’s where I stand, though there is still more to learn if I can replicate this process with the H618 chip on the Orange Pi Zero 2W board, which has a different internal structure regarding DTS files.

I’ll be keeping a close watch as I move forward.

23

Okay, it seems weird, but it works. I guess we need to see how it works on other RK356x SBCs then, with compatible GPIO header, since the sound node is board-specific. So it exists in the Orange Pi 3B dts, but on other SBCs it might be different. Just checked, it can even have a different name. E.g. Quartz64 Model A has no sound node, but uses a RK817 PMIC, as well in the dts and references it in a rk817-sound node instead:

	rk817-sound {
		compatible = "simple-audio-card";
		simple-audio-card,format = "i2s";
		simple-audio-card,name = "Analog RK817";
		simple-audio-card,mclk-fs = <256>;

		simple-audio-card,cpu {
			sound-dai = <&i2s1_8ch>;
		};

		simple-audio-card,codec {
			sound-dai = <&rk817>;
		};
	};

Quartz64 Model B is identical to Orange Pi 3B:

	sound {
		compatible = "simple-audio-card";
		simple-audio-card,format = "i2s";
		simple-audio-card,name = "Analog RK809";
		simple-audio-card,mclk-fs = <256>;

		simple-audio-card,cpu {
			sound-dai = <&i2s1_8ch>;
		};

		simple-audio-card,codec {
			sound-dai = <&rk809>;
		};
	};

Actually interesting that aplay -l shows “RK817” on the Orange Pi 3B, which uses and references an RK809 PMIC. Maybe, internally, they share the same driver, and it does not differentiate their names. Anyway, it should not play a role as you leave that sub node untouched anyway. For the overlay, however, it means that you either need to edit all compatible = "simple-audio-card"; node names the exist across (supported) RK356x SBCs, or have different overlays depending on the SBCs onboard audio node name. To avoid proving dummy compatible = "simple-audio-card"; nodes, it is probably best to not set this property in the sound/rk817-sound nodes in the overlay, but the simple-audio-card,name only. So onboard audio nodes which do exist, are renamed and invoked, but such which do not exist in the boards dts, are not probed unnecessarily by ALSA.

24

Hello @MichaIng

Yes, indeed—originally, the DTS for the Orange Pi 3B (like that of the CM4 and its baseboard) includes an active audio node corresponding to the jack connector (card 0 below) and the HDMI connector (card 1).

root@DietPi:~# aplay -l
**** Liste des périphériques matériels PLAYBACK ****
carte 0 : RK809 [Analog RK809], périphérique 0 : fe410000.i2s-rk817-hifi rk817-hifi-0 [fe410000.i2s-rk817-hifi rk817-hifi-0]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
carte 1 : HDMI [HDMI], périphérique 0 : fe400000.i2s-i2s-hifi i2s-hifi-0 [fe400000.i2s-i2s-hifi i2s-hifi-0]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
root@DietPi:~#

With my script for the PCM5102A, the aplay -l command returns the following:

root@DietPi:~# aplay -l
**** Liste des périphériques matériels PLAYBACK ****
carte 0 : PCM5102A [PCM5102A], périphérique 0 : fe410000.i2s-rk817-hifi rk817-hifi-0 [fe410000.i2s-rk817-hifi rk817-hifi-0]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
root@DietPi:~#

With my script for the PCM5122, the aplay -l command returns the following:

root@DietPi:~# aplay -l
**** Liste des périphériques matériels PLAYBACK ****
carte 0 : PCM5122NoMCLK [PCM5122NoMCLK], périphérique 0 : fe410000.i2s-rk817-hifi rk817-hifi-0 [fe410000.i2s-rk817-hifi rk817-hifi-0]
  Sous-périphériques : 1/1
  Sous-périphérique #0 : subdevice #0
root@DietPi:~#

These three operations by editing the /boot/dietpiEnv.txt file

25

Re @MichaIng

I’ve tested with my pcm5102a board this morning without change for the pcm5122 overlay and it works perfectly so i can use a pcm5122 or a pcm5102a with the same overlay :grin::grin:

Ps: i work to test on my opi zero 2w , i post later for that but it seems Ok for a quick test with just the i2c part and service part add to my overlay for my pcm5102a :innocent: