Posts by chewitt

    Code
    (
    DATETIME=$(date +%Y%m%d%H%M)
    sleep 60
    journalctl -b 0 --no-pager > /storage/journal-${DATETIME}.log
    }&

    Create /storage/autostart.sh with that ^ content and reboot, and it will dump the systemd journal to /storage/journal-xxxxxxxx.log one minute after booting. If it fails to connect, note the minute, then reboot until it does connect and then login to pastebing the log from the console. I doubt the log(s) will show anything useful though.

    The LE settings add-on can be accessed from Kodi settings if using the default skin, else it can be found under: Add-ons > Program Add-ons > LibreELEC settings > Network > Wireless Regulatory Domain.

    No errors reported in the log so I'd assume rtw89 is working to the best of its abilities. The one thing to check is setting the Wireless regulatory domain in the LE settings so the radio properties are aligned to the domain set in your router. Sometimes (but not always) the router advertises it and the driver auto-adjusts to match, but I don't see that in the system log, so either the driver doesn't support that kernel capability yet or the router doesn't advertise.

    TBH i've no idea what "internal volume" means. I'm not all-knowing on Kodi topics, but in all the years I've been hanging around this project i've never come accross that term/concept, and I don't recall any similar report in the forum. I also use Airplay several times per week (for many years, currently on RPi5, before on RPi4, before on RPi3B, etc.) and I've never experienced that. That's not to say it can't happen, but if it was a common thing we'd know about it through user complaints.

    I don't really see playback issues with 4K HEVC or VP9 media on S905X/S912 devices I have (other than seek). I hit play, occasionally see some garbage in the first few seconds but then it stabilises and plays to the end withouth issue. I am mostly playing self-ripped media though, and I rarely test PT audio because that involves fiddling with settings, and if you rotate through test installs as often as I do that's a chore to avoid. 4K SDR HEVC will work on an S905 box, but no HDR support in the chip (or tonemapping in software) and no VP9 on the chip. The decoders really do need adjust-refresh enabled so media plays at native rates. If you use a monitor that requires everything to be displayed at 60Hz or don't enable adjust refresh things don't run so well. I have no expectations of EGL rendering or any media with DRMPRIME disabled playing .. it's not how the image is intended to be used.

    If you want excellent hardware with average software; choose any RK or Allwinner chip we support. If you want something with average hardware and excellent software (hint, this is the better combo) get an RPi5. It lacks VP9, but will software decode up to 4K30 with online streams. Everything lacks AV1 right now. There is no such thing as future-proof.

    I've done some testing on a VIM2 board this morning. I can get DTS-core PT, but not DTS-HD MA PT, and my AVR is silent; unlike the N2+ that I tested which tried to fly my tweeters with noise. The fact S922X outputs noise and S912 does not is probably down to the different audio card drivers used, and the fact both are affected probably points to an issue in the common DRM layer; I'd guess the HDMI frame packing needs tweaking or some additional register poking to work, or something of that nature. S905X3 (SM1) is a minor evolution of S922X (G12B) hardware so will have the same issue. Comparisons with the legacy codebase are entertaining but have no technical merit as the kernel codebases are completely (100% of code) different.

    As a general rule H264 playback is solid and HEVC works 'okay' with adjust-refresh (start/stop) and PCM output. Don't expect HEVC seek to always work (the drivers aren't finished). Don't expect 3D and deinterlacing to work (not implmented) and poorly encoded media stolen from torrent networks will give poor results. The vendor codebase has a ton of hacks in ffmpeg to workaround media issues, and we don't replicate that. As per release notes, AMLGX works for a steadily increasing number of people, but it will not work for everyone.

    It should be using rtw89 which is a native kernel driver (not an external Realtek vendor driver). There isn't much we can do if the driver isn't performing well other than look at https://patchwork.kernel.org/project/linux-…e=&archive=both to see if there's anything we could backport that sounds/reads like a match; although usually the user report isn't technical enough and the patch descriptions are too deep-technical for an easy correlation of problems to patches.

    Please run "dmesg | paste" and "lspci -nnk | paste" and share the URLs so we can see if there's any specific errors and to confirm the exact hardware being used.

    I've made some progress in the last week or so with hardware decoding of 10-bit media and I now see a black screen when playing 10-bit HEVC content. That might not sound impressive, but not instantly crashing the SoC when opening the codec is a huge leap forwards since it allows meanginful further testing to be done; and I can now see there is a load of plumbing missing in ffmpeg that's related to V4L2 format modifiers that's needed to complete the puzzle.

    I've also replicated the DTS-HD MA issue in recent days. I'm not sure what the source of that issue is, but as the Kodi side of things works with multiple other SoC platforms it's almost certainly something specific to Amlogic chips and suspicion falls on the AXG audio driver and/or the HDMI related code in the DRM layer. I need to run tests with an older S905X or S912 device to see if the same issue is present on them or not?. If not, that probably narrows the issue to the AXG audio driver (as the DRM code is common; although there are different code paths in places) and if it also doesn't work on GXL/GXM boards it could be something missing in both AXG and AIU drivers, but more likely something in common DRM code. I'm a little fixated on the codec work at the moment though so might not get around to that test quickly, and even once it's done all I can really do is flag the issue to the upstream kernel maintainers. So for now .. DTS core is all that works.

    antonvier Kodi detects audio capabilities based on the EDID data on the HDMI connection. It's also odd that the kernel detects the audio hardware, but Kodi then fails to open the device(s) to check properties. The very limited list of resolutions shown here would normally suggest a problem in the display chain. That can result in failure to detect normal 1080p/4K modes etc. but doesn't explain the lack of audio hardware.

    Code
    dtoverlay=vc4-kms-v3d
    max_framebuffers=2
    hdmi_enable_4kp60=1

    Comment the above ^ out in config.txt. Disabling 4K60 (which 99% of users don't need, 4K30 is enough) also reduces the power draw which might help with an inadequate PSU issue. That's the only real red-flag that I can see; insufficient stable power (under-rated for current normally) will sometimes manifest all kinds of weird issues. RPi4 needs 5V/3A to be stable. Recycled phone chargers or using USB ports on a TV/monitor generally won't work. Check the PSU out. Also check cables/ports, and if you inflicted self-punishment with an Argon case, remove the board from the case before retesting.

    Any difference?

    FWIW, I can replicate the original issue report of no DTS-HD-MA audio. I've no idea what the problem is though, other than it's most likely to be an issue in the DRM layer, and right now (and since I only use PCM output in testing) I'm not motivated to look into the issue further. I am highly confident the issue is specific to Amlogic hardware so no need for you to find RPi threads and make "me too" posts there, it's only adding distraction to other people's (different) issues.