perlian Posted February 12, 2019 Posted February 12, 2019 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 ?
s_frit Posted February 18, 2019 Posted February 18, 2019 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.
Exie Posted February 18, 2019 Posted February 18, 2019 @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.
Exie Posted February 18, 2019 Posted February 18, 2019 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.
s_frit Posted February 18, 2019 Posted February 18, 2019 I just posted a mixer configuration for NanoPC T4. Probably it works for M4 too: I wonder whether FriendlyElec are shipping an asound.state file with their distribution?
s_frit Posted February 19, 2019 Posted February 19, 2019 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
Exie Posted February 19, 2019 Posted February 19, 2019 @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.
s_frit Posted February 19, 2019 Posted February 19, 2019 Great to hear that worked @Exie Hopefully we can get a fix into the device tree to route that clock correctly. I'm not exactly sure why the clock assignment was deleted.
s_frit Posted February 19, 2019 Posted February 19, 2019 @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.)
Igor Posted February 19, 2019 Posted February 19, 2019 2 minutes ago, s_frit said: Will you accept a patch that reinstates the &i2s1 entry (stops its removal by friendly-arm-hangs-without.patch#L85)? If it doesn't break anything, sure.
s_frit Posted February 19, 2019 Posted February 19, 2019 @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.
Exie Posted February 20, 2019 Posted February 20, 2019 @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!
s_frit Posted February 20, 2019 Posted February 20, 2019 @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.
xfhjk Posted September 10, 2019 Posted September 10, 2019 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
s_frit Posted September 11, 2019 Posted September 11, 2019 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.
Recommended Posts