Cracking / Popping audio - HDMI - LibreELEC (official): 9.95.1 (RK3399.arm)

Quote from knaerzche

Nope. no paths have to be changed - but Rock pi4 needs special handling of emmc.

I did some tests with armbian.

Release 21.02.3 with kernel 5.10.21 boots right from emmc without special treatment.

Writing image with usb-emmc adapter is sufficient.

But no other linux-image I tried is able to boot from emmc.

armbian offers a dialog helper tool, which could enable kernel 4.4 to boot from emmc. But apparently, that helper tool changes boot code of rockpi board. I prepared a emmc with one rockpi and after mounting the emmc to another board, it did not boot.

Quote from knaerzche

Please take a spare SD card, flash the latest nightly (no update) on it and replace the device tree with the with this one: https://mega.nz/file/vHZ21D5R#…dUVYUJezmP6fPfo , where I increased that clock:

Could you please tell me, which value you changed to increase the clock?

I decompiled your file and did a diff to mine - but I only found lot of additional/changed phandles, my changes and the symbol list at the end (in my file).

As I changed dtb too, I'd like to do the changes manually.

Quote from tony013

Release 21.02.3 with kernel 5.10.21 boots right from emmc without special treatment.

Writing image with usb-emmc adapter is sufficien

Armbian has a lot of patches, I didn't check them. For emmc I just did what the vendor does arm64: dts: set emmc max frequency to 150000000 for ROCK Pi 4 · radxa/kernel@db9dfc2 · GitHub.

Quote from tony013

but I only found lot of additional/changed

check again - there is one

Both audio and emmc adaptions will be available in nightlies which are still building for RK3399 they will be available soon. As I've said before: all this is just guesswork, since I'm not having a rock pi4 board yet - none of them is a problem for rockpro64 board.

After the nightly image 20210511 was written to the EMMC module, rock pi 4 stopped loading at all, even from the sd card Only physical removal of the module and formatting it through an adapter helped

Quote from Mikhail

After the nightly image 20210511 was written to the EMMC module, rock pi 4 stopped loading at all, even from the sd card Only physical removal of the module and formatting it through an adapter helped

I'm not sure I understand what you're trying to say. Provide a (uart) log, I guess thats more helpful.

Quote from knaerzche

Armbian has a lot of patches, I didn't check them. For emmc I just did what the vendor does arm64: dts: set emmc max frequency to 150000000 for ROCK Pi 4 · radxa/kernel@db9dfc2 · GitHub.

Thank you for that link!

Quote from knaerzche

check again - there is one

I did - and comparing it with the link from radxa, neither my dtb from LE nightly nor your dtb from posting #13 does contain a section with "&sdhci" - and for so no property "max-frequency".

Could it be, that the kernel module for sdhci isn't enabled yet?

Quote from knaerzche

I'm not sure I understand what you're trying to say. Provide a (uart) log, I guess thats more helpful.

Do you need a usb to ttl cable for this? Unfortunately, I have not. Simply put, if you write the image (20210511) to emmc, turn on the power, the rock pi 4 will not boot either from the emmc or from the sd card, there will be no signal to the hdmi, it will not react to anything until the emmc is cleared.

I just tested nightly (20210511) - but only with sdcard. Have to wait until next emmc will arrive.

I decompiled the dtb and found the max-frequency change. It is quite different from radxa stuff, but anyway - seems to work.

Clock-summary now shows 297000000

So I added my changes to that dtb and both changes work so far.

Nice work! Thank you

Quote from knaerzche

As I've said before: all this is just guesswork, since I'm not having a rock pi4 board yet - none of them is a problem for rockpro64 board.

How did you apply the dtb-changes to LE image creation?

I'm looking for a way to enable pwm modules during LE build, so that I don't have to manually exchange dtb file.

Could you tell a bit about your experience with rockpro64?

Is it better supported than rockpi4?

From what I found, it is a different manufacturer, but as far as I could differentiate it, rockpi4 (with sata-hat) fits better my needs.

Quote from tony013

Could it be, that the kernel module for sdhci isn't enabled yet?

Nope.

Quote from tony013

Could you tell a bit about your experience with rockpro64?

That actually the RK3399 board I'm developing with - I never had any sound issues nor emmc issues (I'm using an emmc module for booting LE there, too)

For the emmc issue on rock pi4: I won't waste yours and my time with further attempts to make it work until I actually have a board.

Quote from knaerzche

That actually the RK3399 board I'm developing with - I never had any sound issues nor emmc issues (I'm using an emmc module for booting LE there, too)

That sounds phantastic!

Well, I bought the rockpi because I wanted a penta-sata-tower ...

... but when you use the tower, you notice the extremely questionable design -

The sdcard slot is hidden by the internal sata connector and that connector is so bad built, that it breaks if you connect/disconnect the cable more than 5 times or so.

With the tower you can't change sdcard, nor emmc and changing usb drive seems not to work either. Therefor I'm searching for multiboot - everything common with a standalone pi does not work with that tower.

On the other side: it works just nice and without any noise - really love it.

... and after fan control I work on supporting top panels button.

I am using RP4 bcm2711 (I mean what shows up in my audio list after activating dtparam=audio=on is bcm2835, the files on flash are named bcm2708-11) and fixed the crackling by just disabling hardware acceleration with DRM PRIME.

Am I missing any performance/quality? Or is this the best way? Can I get a clock updated dtb file?

Just tried 10b3 and the problem persists. Every video 1080p or greater has a muffled/crackling/popping sound when using DRM PRIME HW acceleration. What could be the problem?

Upgraded to LibreELEC RC1, crackles still occur during video playback. During this time, an SBC ROCKPro64 came to me, there are the same problems with sound, crackling, from which I conclude, problems with sound on the RK3399 do not depend on the SBC. On the 4.4 kernel, it was once possible to eliminate them (RK3399 HDMI audio quality), I hope that on 5.10 it will be possible to do the same.

One important note, I should have tried it before, with hardware decoding disabled, the sound is absolutely normal, crackling sound occurs ONLY when the video is played with hardware decoding enabled (DRM PRIME).