Jump to content

Sound problems with NanoPi M4


perlian

Recommended Posts

I have Armbian running on my NanoPi M4

Everything is fine but..............

I have massive problems with pulseaudio

Im not able to get the sound working

So i tried to deinstall pulseaudio and install Alsa

After that i dont see anything regarding sound in settings menu or on the taskbar

For unknown reasons the wallpaper has resettet

Anyone who has a solution ?

 

 

Link to comment
Share on other sites

What does "massive problems" mean? Can you be more specific?

 

People have reported that HDMI sound worked with NanoPC T4 but that the headphone jack did not work. Are you trying to use the headphone jack?

 

I can't help you with pulseaudio or alsa install. But I think that the issue with the headphones jack is with alsa mixer settings. I have headphones working on NanoPC T4 now. Maybe the fix is the same for M4.

Link to comment
Share on other sites

@perlian may be onto something.

 

I just compared the FriendlyElec image to the Armbian one.

FriendlyElec worked, Armbian doesnt.

 

To test I used this for 3.5mm audio jack:

aplay -D default:CARD=realtekrt5651co test.wav

I used this for HDMI:

aplay -D default:CARD=rockchiphdmi test.wav

 

I'm not smart enough to know what the difference is sorry.

Using `aplay --list-pcms` shows both devices on both images.

At a guess, the FriendlyElec one must load/configure some extra module or something.

Link to comment
Share on other sites

Just a follow up, I decided to tinker with this problem for a bit as I had a working configuration and a non-working one.

Eventually, it now works in the Armbian image.

 

I think the trick was to install Alsa and then configure a bunch of settings. I did a diff with the config on the other image and heres's the settings I had to set:

amixer set 'HPO L' on
amixer set 'HPO R' on
amixer set 'HPOVOL L' on
amixer set 'HPOVOL R' on
amixer set 'HPO MIX HPVOL' on
amixer set 'OUT MIXL DAC L1' on
amixer set 'OUT MIXR DAC R1' on
amixer set 'Stereo DAC MIXL DAC L1' on
amixer set 'Stereo DAC MIXR DAC R1' on

 

After setting those, the above test case works on 3.5mm AND HDMI out.

 

I hope this helps.

 

PS. It could just be my ears, but there appears to be a significant drop in quality from HDMI to Analog. There may be further settings to improve this that I have not explored.

Link to comment
Share on other sites

20 hours ago, Exie said:

Just a follow up, I decided to tinker with this problem for a bit as I had a working configuration and a non-working one.

Eventually, it now works in the Armbian image.

@Exie are you using the 4.4.y legacy kernel, or a newer kernel?

 

The reason I ask is that the Armbian build removes a device tree clock assignment for the I2S1 clock that I thought would be necessary for the NanoPi M4 codec to work properly:

https://github.com/armbian/build/blob/master/patch/kernel/rk3399-default/friendly-arm-hangs-without.patch#L85

 

Would you mind posting the output of the following command while audio is running, please?

sudo cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent

If the output is clk_i2s0, you could try the following and see whether it improves the audio quality (probably best to run this while audio is not playing):

su

echo clk_i2s1 >> sudo cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent

exit

 

 

 

Link to comment
Share on other sites

@s_frit Just a follow up, the image I was using was a bit vandalised there. So I've removed my hats and gone back to a bare bones NanoPiM4 and flashed a new image onto the SD card.

 

I'm using

Armbian_5.76_Nanopim4_Ubuntu_bionic_default_4.4.174.img

Which is one I build in a Virtualbox VM.

 

After starting I used SCP to drop WAV file on it and tested. No audio as expected.

I ran the aforementioned amixer commands, test again, and it works!

As mentioned, quality is poor. So I ran it again, and as you suggested:

root@nanopim4:~# cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent
clk_i2s0

I tried your command, but no change, I then tweaked it a bit as I think I understood the intent, so it looked like this:

root@nanopim4:~# echo clk_i2s1 >> /sys/kernel/debug/clk/clk_i2sout_src/clk_parent

Tested again, and you are correct, good clear audio out the 3.5mm socket.

 

Thanks for the tip, and hope it helps others. I'm not really using mine for audio, but its good to know it's there if I need it. Hopefully @perlian gets nice audio too now.

Link to comment
Share on other sites

@Igor The fix for the audio quality issue on NanoPi M4 is to reinstate these lines in the rk3399-nanopi4-common.dtsi:

 

Spoiler

&i2s1 {
	assigned-clocks = <&cru SCLK_I2S_8CH>;
	assigned-clock-parents = <&cru SCLK_I2S1_8CH>;
};

This routes the i2s1 master clock to the i2s_8ch_mclk pin that is connected to the rt5651 codec. (On the other hand, on the NanoPC T4 the codec is connected to i2s0 so this clock assignment is not needed --  SCLK_I2S0_8CH is the default parent of SCLK_I2S_8CH).

 

Those lines are being removed by this Armbian build patch here: 

https://github.com/armbian/build/blob/master/patch/kernel/rk3399-default/friendly-arm-hangs-without.patch#L85

 

Note that &i2s1 is disabled by default, and only enabled on NanoPi M4, where i2s1 is connected to the on-board codec.

 

Those lines are also useful if you want to use the i2s1 interface on the NanoPC T4 40-pin header, which is why it makes sense for them to be in the *-common.dtsi file.


@Igor Will you accept a patch that reinstates the &i2s1 entry (stops its removal by friendly-arm-hangs-without.patch#L85)?

 

Sidenote: @hjcJust a heads-up: I'm fairly certain that the same fix is needed for the firefly rk3399 board. The same clock assignment generally appears in rk3399 boards when using i2s1 and the codec is not configured as master. For example the following rk3399-firefly-core.dtsi is included by many configurations, and performs the same clock mapping (also another GPLL mapping that I don't think is always needed):

https://gitlab.com/TeeFirefly/FireNow-Nougat/blob/firefly-rk3399/kernel/arch/arm64/boot/dts/rockchip/rk3399-firefly-core.dtsi#L519

(But maybe firefly board also needs other ALSA mixer configuration for the codec before this can be tested.)

Link to comment
Share on other sites

@Exie Would you mind testing the attached NanoPi M4 device tree (rk3399-nanopi4-rev01.dtb) with your  Armbian_5.76_Nanopim4_Ubuntu_bionic_default_4.4.174 image please?

 

rk3399-nanopi4-rev01.dtb

 

Copy it to /boot/dtb/rockchip (perhaps rename/backup the existing dtp first), then reboot.

 

The result should be that you can play audio (with amixer commands) without any other clock manipulations. `cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent` should report `clk_i2s1`.

 

Once you confirm that this works I will submit a pull request to get this fix included in the next Armbian build.

Link to comment
Share on other sites

@s_frit No problem.

 

I did as you said, just using the amixer commands above, rebooted and the audio came out crystal clear.

 

Nice work!

 

I'm still learning about device tree overlays and what their role is, I watched some youtube videos but I think they went way over my head, especially when they went into SPI datasheets! :)

Link to comment
Share on other sites

@ExieGlad it worked, thanks for testing it!

 

I've submitted a patch to the Armbian github. Hopefully this will get included in a future release. https://github.com/armbian/build/pull/1289

 

By the way, I notice that Armbian provides a way to include an asound.state file as part of the distribution. That should allow working mixer settings to be shipped with Armbian.

Link to comment
Share on other sites

On 2/20/2019 at 5:50 PM, s_frit said:

I've submitted a patch to the Armbian github. Hopefully this will get included in a future release. https://github.com/armbian/build/pull/1289

Thank you very much for looking into this and making that asound.state above. However, is that the right patch? It was was included, but it looks like some unrelated changes are in there too, like (if I'm reading it right) disabling the FIQ debug port?

https://github.com/armbian/build/commit/fa78fdfbc74d6abfb8e16475b474e1f5eb472bb2#diff-21bb4eb457b6fafdb9c183440b888782

Link to comment
Share on other sites

22 hours ago, xfhjk said:

However, is that the right patch? It was was included, but it looks like some unrelated changes are in there too, like (if I'm reading it right) disabling the FIQ debug port?

https://github.com/armbian/build/commit/fa78fdfbc74d6abfb8e16475b474e1f5eb472bb2#diff-21bb4eb457b6fafdb9c183440b888782

 

Yes it is the right patch. It is a "patch to a patch". The lines that seem irrelevant are just context lines in the patch that is being patched.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines