Posts by knaerzche

    I compared vendor with mainline kernel for anyting which could belong to hdmi audio - all I could find, that could help was, that dmac clock is higher in vendor kernel.

    Mr.Tiptop  Mikhail

    Please take a spare SD card, flash the latest nightly (no update) on it and replace the device tree with the with this one:…bzl2NgnAgXdUVYUJezmP6fPfo , where I increased that clock:

    scp rk3399-rock-pi-4a.dtb [email protected]<ip of device>:

    login via ssh:

    ssh <ip of device>

    move devicetree to flash partition:

    mount -o remount,rw /flash/
    mv /storage/rk3399-rock-pi-4a.dtb /flash/



    . It does make zero difference on my boards (never had audio issues with no bit-/or sample-rate) - but it might make a difference for rockpi4 (dram maybe slower). Do not enable passthough (this is experimental and will go away before final LE10 release) and don't touch any audio settings. If everything went OK

    cat /sys/kernel/debug/clk/clk_summary | grep dmac

    should look like that:

    aclk_dmac1_perilp       0        1        0   297000000          0     0  50000
    aclk_dmac0_perilp       1        2        0   297000000          0     0  50000

    Please check if it makes any difference for you for audio output.

    by the way, when will LibreELEC 10 be able to boot from EMMC?

    If you're using a detachable emmc module, feel free to flash the image there - its working great witch rockpro64. (and upstream device tree for rockpi4 has emmc enabled as well)

    Perhaps this is not a problem with all RK3399 SoCs, but only Rock Pi 4B on the new kernel.

    Yeah, looks like. I can't hear any cracking on neither my RK3399 TV box nor on rockpro64. Its kind of hard to do some remote guesswork - can you upload a audio record to get a feeling, what is actually meant with "cracking" and also link to the stream which you played at that time?

    Thanks for the logs, I will have a look at them. No worries for the "missing" lines - they are not related to CEC - actually its debugging stuff, which shouldn't have logged by default in LE 9 as well :)

    From a quick glance: I see a lot of

    Tx, Error (1), Max Retries

    messages in LE 9 logs as well - I guess you already tried a different HDMI cable?

    yeah, there seems to be a 2160p resolution issue with the file, but if you switch to 1080p resolution it comes back to business as usual (I tried various frame rates, but 2160p is broken right now). easyb do you also have a similar problem on your end?

    Its not "broken".

    The reason you are seeing "green flickering" (I guess) is, that the dram bandwith required to display 4k is to high.

    The vendor kernel raised the dram frequency applied correct dram timings - this does not exist in upstream kernel (yet) and the dram frequency will be stuck at ~ 300 MHz with standard timings which propably do not match the those required for the dram chips in your box - so everything will be (very) slow.

    The only way around that is currently, to completely(!) erase the emmc, so that dram init is done from sd card, where we initialising the dram with 786 MHz (with standard timings, though). There will be an update for that sooner or later for LE for selected devices.

    Overall: Its recommanded to use SBC boards, which do not have android pre-installed, so that the complete boot process is done from SD card oob

    I can see, I was not so clear regarding describing the situation. So, let me rephrase it again:

    Thanks, seems clearer now.

    So - the only difference, I can see between the two cec-ctl monitor logs is ,that my TV annouces it went to standby with

    Received from TV to all (0 to 15): STANDBY (0x36)

    what is completly missing in your log - this way the HDMI controller "knows", that the device will be re-requesting the same address at some later point.

    Time to time I can see in dmesg ouput LOW_DRIVE status but I cannot figure when the message appears. I checked source code and patches a found that it could be this part of code responsible for that in file

    This is a required patch for some other TVs - without it, CEC wasn't working at all for them. I don't think its releated to this problem. But it would be interessting, if your are seeing this message when switching your TV off.

    Interesting is that LE 9.2.6 worked properly without any issue. I can setup 9.2.6 again and check the messages, if you wish...

    That could be helpful.

    I'm not sure, if your TV has that option - could you also try to search for CEC devices (should be somewhere in the settings menu of your TV) after you switched it on again and paste the cec-ctl -m

    Better don't compare it to Rockchip, Amlogic or Allwinner - they needed 4+ years and are partly not even there yet

    you should know better.

    I tend to disagree (except about AML part) :)

    Me too (what a suprise).

    I'm not really aware what Rpi currrently supports - but reading the comments suggest, it doesn't support [email protected], and no proper h264 decoding (beside sw) - which is sort of essential these days. Both is well working on RK/AW. No differences for HDR (everything is still 8-bit output, but sends HDR infoframes).

    That it takes longer is kind of in the nature of things (I can only speak for RK) - RPi is kind of a single use-case SoC, while other SoCs have way more HW compontents to support - media stuff is not always (never) 1st priority.

    It looks like your TV doesn't announce that he went to standy - so HDMI controller doesn't "know", that the TV disappeared from CEC bus.

    After reading your report again: With "power cycle" you mean: cut off power completly? This way it can't (currently) work, since HDMI controller will continue to poll the old CEC address endlessley, while your TV will ask for a new (maybe even the one it had before) when you switch it on again. If this is possible it would be better to put TV in standby first and cut off power after that.

    The only way arround that (I can think of), is to ask TV to "search" for CEC devices again and reconnect.

    For the HW side there are no differences which couldn't be captured by the device tree.

    The reason why images won't boot is, that there is a SoC Id check in (vendor) ATF, which will fail on RK3318.

    If I find time, I'll try to find a way around this and will add RK3318 support.

    Dolby Digital works fine also with Atmos😊 the DTS works sometimes but When I activate TrueHD and DTS-HD I get just noises.

    as jernej mentioned there is no support for HBR audio in the upstream HDMI driver (yet) and I'm slidly suprised that it works on android, since vendor kernel doesn't seem to have that implemented as well.

    If your AVR support HBR audio via SPDIF, its worth a try to check if this works. (Note: Bitstream parsing is currently partly broken / unmaintainted on kodi side, which is propably the cause why DTS works only sometimes). There is also an part-fix for compressed audio pt which didn't make it into beta2 release - its available in current nightlies.