Posts by chewitt

There's nothing in the logs related to wireless other than rtw89 driver probe/load and some basic radio info from iwd. You can see connman cycling through some device up/down states, but that's not abnormal. I can't see any attempt to associate to a network in the log.. but that could be for a multitude of reasons.

Not possible as 100% (255) is the maximum allowed value. There are probably ways to use alsa plugins to reroute and boost the audio signal in some way, but that's not something I have any experience with or want to research; Google searching alsa config topics is always a rather miserable task.

List audio devices:

RPi5:~ # aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

In my case this is an RPi5 and I'm using the HDMI-0 connector (nearest the PSU) which is vc4-hdmi-0 .. so 0 is the card.

List simple controls available on the device:

RPi5:~ # amixer
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]

Using amixer to reduce the volume to 80%:

amixer sset 'PCM' 80%

Checking:

RPi5:~ # amixer
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 204 [80%] [-10.20dB]
  Front Right: Playback 204 [80%] [-10.20dB]

More granular control is achieved using amixer set commands and using amixer controls and amixer contents to understand what can be set and what current values are. The alsamixer tool just provides a console GUI onto the same capabilities.

I'm not sure we can set/store the changes in a persistent way, but the workaround is to use /storage/autostart.sh scripts or (better) a systemd service to run commands on boot. The example WireGuard service in /storage/.config/system.d/ shows an example of running connmanctl commands to start a connection. You can adapt that to run amixer commands, and schedule dependencies so the service runs after alsa is setup (sound.target) and before Kodi runs (kodi.target).

I got rather distracted with some recent discoveries on the hardware decoders. I need to circle back and cherry-pick the older device tree and then do some fixups for changes; some of the kernel bindings have evolved since LE11 days.

Quote from Cissou

it works, but I need to do the command every boot

Then you need to script the commands to execute on each boot. This is best done via a systemd service as this gives you precise control over dependencies and scheduling, e.g. after bluetooth is up, and before Kodi runs.

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

"lspci -nnk | paste"

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.

On some minimal remotes you need to press the OK/Enter key to bring up the OSD and then navigate to stop. The solution to that is using a less minimal remote with an actual stop button.

The only update in recent weeks is LE 12.0.0/1 to 12.0.2 and testing whether that changed anything (not impossible but unlikely) is easy to test by rolling back to the earlier version.

If the wiki is wrong, anyone can submit a correction.

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.

Quote from Da Flex

Make sure your graphics card driver is up-to-date

In this case driver means the firmware for the LSPCON chip.

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.

5V/2.5A should be usable (esp. with 4K60 disabled). Before you purchase a replacement PSU, find a spare SD card and boot the latest RaspiOS image. If this also shows an issue with HDMI audio it points to a hardare issue. If it works, the issue is software.