Posts by HarryH

  • LibreELEC 12.0 on Raspberry Pi5

    Only to be sure, do you use a case for your RPi5 like the Argon ONE V3? I'm asking because this case doesn't pass-through the PD information to the RPi5. The case pcb is self a power sink and negotiates the power consumption with the power supply. But the connection RPi5 <-> case pcb doesn't negotiate via PD (power delivery).
    The RPi5 relies on that power delivery information, to enable the whole 5A current and additional the USB boot support/max. USB current.

    In such case, you need to add this lines to bootloader config /EEPROM:
    PSU_MAX_CURRENT=5000

    and to your config.txt:
    usb_max_current_enable=1

  • Only 6.1 LPCM for 7.1 sources with Raspberry Pi

    Thank you for providing the additional image.

    Only for sureness, I have tested with different KODI LPCM audio and video sample files: https://kodi.wiki/view/Samples

    With the official 12.0.0 image the mapping was wrong (6.1 -> RC)

    and after update to the image with the patch provided by you it's now correct 7.1 (RLC/RRC):

  • Only 6.1 LPCM for 7.1 sources with Raspberry Pi

    Hi HiassofT , chewitt ,

    thank for your both comments/doings. Yesterday night I tested just for a short time window with the sample multichannel FLAC files. But there was some strange behavior, which has looked like the issues that _marklam_ reported.
    Yes, I prefer the passthrough way too. My RPi4 and my AVR are able to support that. But the current use case of multichannel FLAC (7.1 LPCM) files differs a little bit. I’m interpreting this as the only available way to get („passthrough“) the multichannel audio lossless to the speakers.

    chewitt
    I will try the image you provided and give you a feedback. It would be nice, if _marklam_ will test it with real music files and hopefully can confirm that it‘s working now. :)

    EDIT:
    The image chewitt has provided is for RPi2/3 only, so I can't test it with my RPi4. _marklam_ it's now your turn. ;)

  • Only 6.1 LPCM for 7.1 sources with Raspberry Pi

    Hi chewitt ,

    thank you for the clarifying. But currenly I'm little bit confused and get a node in my head. Do you have a perhaps a link to a sketch about the different positioning of SL/SR vs. BL/BR vs. BLOC/BROC speakers please?

    I'm asking because my DENON 3808 AVR reports this setup via HDMI (EDID decode) and thinking the SONY AVR of _marklam_ behaves the same :

    Code
     Speaker Allocation Data Block:
   FL/FR - Front Left/Right
   LFE1 - Low Frequency Effects 1
   FC - Front Center
   BL/BR - Back Left/Right
   BC - Back Center
   RLC/RRC - Rear Left/Right of Center (Deprecated)

    This 7.1 AVR has 6 terminals for 2x Surround A + 2x optional Surround B and additional 2x Surround Back Left/Right speakers. The Surround A terminals should be used for a 5.1 setup and the speakers placed sideways or little bit behind of the main seating.

    Currently I think BL/BR is mapped to Surround A + B and RLC/RRC is virtual in 5.1 mode. Because I currently haven't a 7.1 speaker setup I can only relies on the reported input signal.

    In that sketch for the 7.1 speaker setup example, it looks to me
    https://www.intel.com/content/dam/support/us/en/images/mini-pcs/7.1.jpg

    • that BL/BR is moved to my assumed RLC/RRC position
    • and SL/SR replaces my assumed BL/BR position

    During my research I found this kind of adapters too: https://www.allaboutadapters.com/au-hcp2.html I'cant see a different positioning for SL/SR vs. BL/BR

    I'm wonder if AESinkALSA should doing the same with LPCM 7.1 media files?

    • map media SL/SR -> HDMI BL/BR channel
    • map media BL/BR -> HDMI RLC /RRC channel

    Being I'm totally wrong with that idea? Or does all others 7.1 receivers advertise SL/SR via HDMI additional?

    EDIT:

      HiassofT Could it be that there is already an option for that, but a condition is wrong (channel replacement looks not executed) :?:

    xbmc/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp at 7c7f08a545d6011aa05c0ece2b960452b65e3457 · xbmc/xbmc
    Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…
    github.com

  • Only 6.1 LPCM for 7.1 sources with Raspberry Pi

    It looks to me that the speakers that are requested not matching the speaker setup reported by your amp. The channels SL and SR are not listed by your amplifier.

    Code
    2024-04-30 11:57:42.244 T:901      info <general>:     Device 4
2024-04-30 11:57:42.244 T:901      info <general>:         m_deviceName      : hdmi:CARD=vc4hdmi,DEV=0
2024-04-30 11:57:42.244 T:901      info <general>:         m_displayName     : vc4-hdmi (vc4hdmi)
2024-04-30 11:57:42.244 T:901      info <general>:         m_displayNameExtra: SNY SONY AVAMP on HDMI
2024-04-30 11:57:42.244 T:901      info <general>:         m_deviceType      : AE_DEVTYPE_HDMI
2024-04-30 11:57:42.244 T:901      info <general>:         m_channels        : FL, FR, LFE, FC, BL, BR, BC, BLOC, BROC
2024-04-30 11:57:42.244 T:901      info <general>:         m_sampleRates     : 32000,44100,48000,88200,96000,176400,192000
2024-04-30 11:57:42.244 T:901      info <general>:         m_dataFormats     : AE_FMT_RAW,AE_FMT_S24NE3,AE_FMT_S24NE4,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_S16BE,AE_FMT_U8,AE_FMT_RAW
2024-04-30 11:57:42.244 T:901      info <general>:         m_streamTypes     : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD,STREAM_TYPE_DTSHD_MA,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512,STREAM_TYPE_EAC3,STREAM_TYPE_TRUEHDz

    Requested by the play process:

    Code
    2024-04-30 11:58:26.562 T:902     debug <general>: CAESinkALSA::GetChannelLayout - Requested Layout: FL, FR, FC, LFE, BL, BR, SL, SR
2024-04-30 11:58:26.562 T:902     debug <general>: CAESinkALSA::GetChannelLayout - Got Layout: FL, FR, LFE, FC, BL, BR, BC, UNKNOWN1 (ALSA: FL FR LFE FC RL RR RC NA)


    I have seen in the manual of the amplifier, that it supports different speaker schemes. How many and which type of speakers do you have? Maybe you should ensure to set it to 3/4.1 and try it again.

    Edit: Some minutes ago I have looked into my kodi.log. With my receiver I get also BLOC and BROC instead of SL/SR reported. I will test it tomorrow with that files if I come to the same result like you:

    GitHub - sfiera/flac-test-files: FLAC test files for multi-channel sound systems
    FLAC test files for multi-channel sound systems. Contribute to sfiera/flac-test-files development by creating an account on GitHub.
    github.com

  • Only 6.1 LPCM for 7.1 sources with Raspberry Pi

    Can you please more specific?

    - which RPi? 1, 2, 3, 4, 5 ?
    - which LE version?

    The best way to provide the needed details is to enable debug logging (Settings → System → Logging), reboot and paste here the link to the log only:
    https://wiki.libreelec.tv/support/log-files

    If you currently use LE 11.0.6 or earlier, please try a current nightly - because there was important changes regarding EDID data. EDID data is the source for the audio channel information and must be correct.

  • [RPi5] Problem with HiFiBerry DAC

    Hi Lotte,

    nice, that you found a solution.

    If you currently doesn‘t have a dtoverlay=hifiberry … line in your config it seems that the overlay was instead loaded from the HAT EEPROM. Please keep in mind, that in future kernel versions it could be possible that this overlay in the HAT EEPROM will be outdated. Then you will need a matching dtoverlay line for your hifiberry.

    Regards,

    Harry

  • [RPi5] Problem with HiFiBerry DAC

    Because of this:
    Configuring Linux 4.x or higher | HiFiBerry
    HiFiBerry sound cards on the Pi5 | HiFiBerry
    Changes in HiFiBerry drivers | HiFiBerry

    you should ensure that this line is commented out:
    dtparam=audio=on
    to
    dtparam=audio=off or #dtparam=audio=on

    I had read that this command
    force_eeprom_read=0
    is deprecated, you should instead move this 2 lines to the very beginning of the config.txt

    Code
    dtoverlay=
dtoverlay=hifiberry-dacplushd

    The first line prevents it from loading the overlay out of the HAT EEPROM (hifiberry).

    I know that some users with RPi5 and a Argon ONE case use successful the hifiberry driver set with their new BLSTR DAC modules. But the driver for dacplushd could have his own bugs.

  • [RPi] Argon ONE Control Add-on (Support Thread)

    Okay, this looks like a little bit different constellation. If i'm right, then the remote you using relies on the default remote profiles. Or do you have added an "rc_map.cfg" or "lircd.conf" file manually in the past to get it work?
    You can check if one of these files exists in the "/storage/.config" folder.

    Hint: Instead of a restore the complete configuration, in your case it would be enough to delete the rc_maps.cfg in /storage/.config. Just for completeness also delete the remaining "/storage/.config/rc_keymaps/argon40.toml".

    In this case, I already had on my to-do list to find a working merge solution.

  • [RPi] Argon ONE Control Add-on (Support Thread)

    The Addon can't backup files, which are not exists during installation or after the settings menu was closed with OK.
    Please be aware: The known switch object in the Addon settings menu isn't able to trigger directly an action! This could be create a gap in your idea and needs additional handling. For example if someone will change/add his own files, after the plugin was installed and is already running. Such edge cases must be taken into account.

    I would prefer the way, to add the Argon IR remote to the existing list for coexistence, if that possible. But this depends on how the custom remotes were added.

    Like I wrote before, the Addon (depending on the version) currently add only files to the ".config" directory like rc_maps.cfg and lircd.conf. This are 2 different ways to add a custom remote, but the resulting behavior is different.

    Please can you provide more details, which file(s) you have restored, to make your remote control working again?

  • [RPi5] No Display After Reboot

    Quote from Reddirt

    I had no idea the order in which devices were powered might be an issue. If I understand correctly the RPi5 system will record all necessary EDID info on it's 1st run and save in a permanent file for future boots?

    No, it‘s not saved automatically. The command „getedit create“ is the manual process for that, and „getedit delete“ the counterpart.

    Explanation:

    Since some LE versions, its more important that:

    1. the EDID informations are available
    2. the EDID information must be correct

    Normally the HDMI handshake should be initialized during boot of the RPi. This happens dynamically with every boot process. At this time it‘s important that the HDMI chain is working and not disturbed. Disturbing is possible with bad manufactured/not certified HDMI cables, Micro-HDMI adapter, other HDMI devices …


    For example you should ensure, that you switch on the RPi as the last one if your cabling looks like this:
    RPi5 -> AVR -> TV

    The ideal sequential order to power-on is that:

    1. TV (provides EDID data for screen size/frequencies + supported sound channels/formats)
    2. AVR (passthrough and/or provides additional EDID data)
    3. RPi5


    If the AVR is powered-off, the RPi5 can‘t get the EDID information. Some newer AVRs are able to passthrough the EDID information if they are in standby. But there also exists TV, that only provide this information if the TV is switched on.

    To get a more robust system against the different power-on scenarios, it‘s possible to grab the EDID data one-time and save it in to the file system with the „getedit create“ command. After that the kernel/KODI will use this saved information at the next boot instead of the dynamical available EDID information. But this implies, that this file must match to your current hardware constellation. On this way it also possible to fake some information, if the extracted EDID block is incomplete or something like that.
    If you afterwards make some (conflicting to the EDID file) changes on your hardware/device firmware, then you must update or delete the EDID file again.

  • [RPi] Argon ONE Control Add-on (Support Thread)

    Quote from ApexDE

    Yes, that was my first test: Fan always on. And it didn't work ;) so i thought the addon in general doesn't work.

    I wished, that such issues are reported here, and not silently switched back to an old version. Like the issue above, sometimes I detect that randomly only. And so long I believing all things are fine.

    Quote

    Can you built in a switch for the Argon remote and the others so it doesn't break the other remotes when installing the plugin without the lock file? I believe one should actively choose to use the Argon remote instead of the formerly used one. You could backupcopy the previously used remote files also?

    It's not so easy like it sounds. In my opinion the best way would be, if a dialog were opened during the installation process if a existing configuration has been detected. But it seems that it's currently not supported by KODI for Addons, or I doesn't know the way for.

    Because I wanted to force the migration to the modern way with ir-keytables, it was needed to delete the old lircd.conf, which was provided by the version < 0.0.10. Default this file doesn't exist in LE.
    I don't have a statistic, which way (lircd vs. keymaps) the most users using with their own remote control configuration, and therefore I'm been unsure which files I should check to make this process bullet proof.

    As a simple solution I thought about in the past, to add a switch to create/delete the lock file from menu. But this will not prevent, that your configuration will be overwritten during the first installation of the Addon. To prevent this, I must set the remote control file copy process default to off. It needs a restart of KODI to reload the remote config, as far as I know. But there are also users with the origin Argon IR remote, they need the configuration file from the Addon and may expect that the remote work out of the box, after the Addon is installed successful.

    That's the conflict I'm in.

  • [RPi] Argon ONE Control Add-on (Support Thread)

    Quote from ApexDE

    Why isn't the plugin in the LibreElec repository?

    I doesn't have a automatic build process ready and I honestly currently don't know what's all required to make it part of a LE repo.
    May be I must extent my test scenarios first, to prevent that I publish a buggy version.

    For example, this week I stumbled over the regression, that in version 0.0.13 I introduced throwing of a exception with setting "Fan always on" is enabled. If this setting is set to enabled, the fan isn't running. I thought I have tested, but it seems I didn't.
    Version 0.0.12a shouldn't affected by this. And as temporary workaround with version 0.0.13, you can lower the threshold to get the fan running all the time.

    Such things shouldn't happend with a Addon in a official repo...