s_frit

  • Content Count

    24
  • Joined

  • Last visited

About s_frit

  • Rank
    Member

Profile Information

  • Location
    Melbourne, Australia
  • Interests
    SBCs + Audio IO

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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 shi
  3. @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.
  4. @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
  5. @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
  6. 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.
  7. @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 wh
  8. 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
  9. 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?
  10. 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
  11. 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.
  12. 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
  13. Same problem with `make scripts` with linux-headers-4.4.174-rk3399 Patching net/Kconfig also works around the issue. Thanks.
  14. 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?