s_frit

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.

In case anyone else wants to look at T4 audio I thought I'd leave a few of my notes here, as I need to move on to other things for a while. The device tree audio widgets mention "MICBIAS1" but the rt5651 driver actually uses the lower case string "micbias1". This seems to be a bug in FriendlyElec's .dts (probably copied from some other realktek codec drivers which do use the uppercase spelling). Fixing this fixes an error message in the dmesg startup log. You can confirm this by looking for micbias in the rt5651 driver source code in the kernel tree. Armbian has a mechanism for shipping asound.state with the build. We should work out a canonical asound.state for the T4 and M4 boards and add it to Armbian build. However, I don't know if or how this interacts with pulseaudio. Maybe extra work is needed to get everything to play nice with pulse -- none the less, a working ALSA config would be a good start. I have yet to check this with an analog audio expert, but my reading of the T4 schematic is that the onboard Mic is connected to the codec in differential mode. However, by default the driver configures the codec in single-ended mode. The version of the driver in FriendlyElec's branch doesn't have the device tree binding to allow enabling differential mode for the Mic2 input (later versions of the driver for that codec do). TO TRY: add device tree binding to driver, add appropriate entry to device tree, see whether it improves onboard Mic audio quality. (should reduce noise/increase gain). NOTE: the DT binding docs for that codec which do have the binding for the differential mic input have an error in the docs. they misname the param and say something like diff-param=true; when it should just be differential-param; (not the real names). I'm still very new to Armbian and have no idea whether there are any common practices with regard to setting up audio on new boards. Guidance and feedback would be appreciated.

@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.

@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.

@Igor The fix for the audio quality issue on NanoPi M4 is to reinstate these lines in the rk3399-nanopi4-common.dtsi: @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.)

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.

@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

Now that I've investigated making an ALSA UCM profile, I don't think that's necessary for the NanoPC T4 (although it could be useful for the M4 to distinguish between onboard and headset mic). For T4 it should be sufficient to just overwrite the global asound.state with the file that I posted earler, as follows: sudo cp asound.state.draft.201902018 /var/lib/alsa/asound.state Sidenote: For those who care about gain structure, I found the following values noted as "volumes for 0dB" defaults in plbossart's ALSA UCM profile. Probably with deep enough study these can be deduced from the 5651 data sheet. ADC Capture Volume = 47 DAC1 Playback Volume = 175 HP Playback Volume = 31 IN Capture Volume = 23 OUT Playback Volume = 31

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?

Here is a way to get the onboard audio working on NanoPC T4 (and probably M4 too). It kind-of works with pulseaudio, but I think more work is needed for a good solution for pulseaudio (need to develop a UCM profile). The attached asound.state file will configure the rt5651 codec mixer with sane settings. To use it: Download the attached asound.state.draft.201902018 Run the following command from a terminal (in whatever directory you downloaded the file): alsactl --file ./asound.state.draft.201902018 restore After that you should have working headphone audio and microphone capture. WARNING: this command may make a loud audible thump. Do not wear the headphones when running it. Note that in the absence of a ucm profile, pulseaudio might make its own changes to the codec mixer settings at login, so you should run the above alsactl restore command *after* logging into the desktop. You can try using alsactl globally to save the settings for use after reboot, but personally I have not yet found a good solution -- please let me know if you have any thoughts on permanent save/restore and pulseaudio interop. There is some general discussion about asound.state management here. If you run alsamixer from the command line you can adjust output level using "DAC1" and "HP". Hit F4 for capture, then the gain settings that appear to work for the internal microphone are "ADC", "ADC Boost Gain" and "IN2 Boost". ... So far I developed this configuration with the help of the following resources: plbossart's configuration for baytrail boards using the same ALC5651 codec: https://github.com/plbossart/UCM ALC5651 codec data sheet v0.92 https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/6/ALC5651-DataSheet_5F00_V0.92.pdf (Audio routing diagrams are on pages 4 and 5. Page 4 is the analog routing, page 6 is the digital routing.) NanoPC-T4 Schematic http://wiki.friendlyarm.com/wiki/images/f/f4/NanoPC-T4-1802-Schematic.pdf NOTE: Beyond the codec mixer settings I think there are some things that can be tweaked with the device tree and drivers that may improve the microphone noise floor, but I haven't gone too far into that yet. If anyone is interested I'm happy to share my notes or discuss details of the routings I chose. asound.state.draft.201902018

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.

Hi Destmaster, Sorry about the delay. I've been away. I would check the startup log for relevant messages by running `dmesg`. If you have compiled any loadable kernel modules, check that they are being loaded by running `lsmod`. It would make it easier for people to help if you say exactly what you edited in the dtb. This is a good talk if you haven't seen it: https://www.youtube.com/watch?v=kb1yAt9d2k8 (ASoC: Supporting Audio on an Embedded Board, Alexandre Belloni). A a bunch of troubleshooting suggestions are given near the end. As for device tree overlays: overlays are something you can copy to your /boot dir without having to recompile the base .dtb (and potentially they will keep working after you upgrade Armbian). However I'm not 100% sure how device tree overlays are selected on Armbian (try searching the forum). Here are some links: Add an I2S mic using device tree overlay (on raspi) https://source.android.com/devices/architecture/dto A google search will give a bunch of tutorials and info on device tree overlays.

Workaround for latest `make scripts` issue is described here:

Same problem with `make scripts` with linux-headers-4.4.174-rk3399 Patching net/Kconfig also works around the issue. Thanks.

As far as I can tell, many, if not all, targets generate an identical postinst script for the linux-headers package by patching scripts/package/builddeb. A search of the Armbian build repo for "Compiling headers - please wait" produces 33 code results. This means that improving the postinst script (for example, as discussed here) requires updating 33 patch files. I'd be happy to help improve the situation, but I'm unsure how to proceed. Could we have a global postinst script for the linux-headers package, and somehow copy it into place? or must we use a patch file?