Posts by HiassofT


    Could you upload the full dmesg (just do "dmesg | paste" and post the URL) and lsmod output?

    Are you using userspace lirc (i.e. have you create a lircd.conf in the .config dir)? Are you running ir-keytable or other commands via http://autostart.sh/udev rules/... to setup a custom remote configuration? Which protocol/configuration are you using on your oneforall remote, is it MCE?

    If you are using the nuvoton IR receiver (of your zbox) and the remote configured to (rc6) MCE protocol could you try running "ir-keytable -p rc-6 /sys/class/rc/rc0/" (double check if rc0 really is the nuvoton, it could also be rc1 since you have 2 IR receivers installed) and test if you get any events via "ir-keytable -t"?

    It's quite odd that on the nuvoton IR the only enabled protocol is lirc and not lirc + rc-6. The kernel should enable the rc-6 protocol from loading the rc-rc6-mce keymap. But there's also a kernel bug, even if it enables the rc-6 protocol it didn't load the rc-6 protocol decoder - so decoding doesn't work. Manually enabling the protocol (eg via ir-keytable -p) triggers protocol decoder loading and decoding works fine again. I've already reported that bug and it was confirmed: Bug: decoders referenced in kernel rc-keymaps not loaded on boot — Linux media

    so long,

    Hias

    Could you please test if this build works on your RPi1:
    LibreELEC-RPi.arm-8.0-devel-20170225092739-r25402-g2c2b9b7.tar

    This build contains backported fixes to the clock framework, without that switching between HDMI and I2S audio caused black screen and lockups on the RPi0.

    LE8: add backported RPi kernel fixes by HiassofT · Pull Request #1389 · LibreELEC/LibreELEC.tv · GitHub
    thread-3848.html

    Would be good to know if you are experiencing the same issue or another.

    so long,

    Hias

    I've uploaded a LibreELEC 8.0.0 build with Wolfson/Cirrus card drivers

    RPi: LibreELEC-RPi.arm-8.0.0-HiassofT.tar
    RPi2/3: LibreELEC-RPi2.arm-8.0.0-HiassofT.tar
    Source: GitHub - HiassofT/LibreELEC.tv at 8.0.0-cirrus

    Support for the Wolfson/Cirrus card is now also included in the LibreELEC master branch (which will become LibreELEC 9.0) and in Milhouse testbuilds.

    These 8.0.0 builds are plain LibreELEC 8.0.0 code with backports from LibreELEC master (newer RPi kernel with Wolfson/Cirrus driver plus the config scripts package). I've also included the bcm2835 DMA splitting fix which was present in kernel 4.4 but got missed in kernel 4.9, this should resolve clicking noise when playing back 192kHz audio.

    If you are upgrading from OpenELEC or LibreELEC 7.0.2 or earlier please note that the method to setup custom mixer configurations has changed. The udev rule will no longer work, custom configurations are now handled via /storage/.config/rpi-cirrus-config.sh

    Detailled installation and configuration instructions are on my website: "HiassofT" LibreELEC RPi builds

    so long,

    Hias


    Update: I tried fixing the audio config to 192kHz, but ran into another problem. Input files with sampling frequencies up to 96kHz played back fine, but files at 192kHz didn't - the audio was chopped up a few times per second, sounding terrible.

    Thanks for reporting back!

    I could reproduce the issue here, turned out that I already fixed this bug (in the bcm2835 DMA controller driver) last june but it somehow got lost during upstreaming. I've resent the path to the LKML and will include it in the upcoming LE8 Cirrus build.

    so long,

    Hias

    Thanks for the info!

    I could now reproduce the issue locally (using gpio-ir-recv on RPi with the rc-streamzap keymap) and it looks like we are facing 3 issues here:

    1) The kernel doesn't seem to automatically load the rc5 protocol decoder (which handles the "rc-5-sz" RC5 streamzap protocol) when the streamzap module is loaded.. LE 7.0.x / kernel 4.4 dmesg contains the line "IR RC5(x/sz) protocol handler initialized" which is missing in 4.9/4.10 kernel logs. This seems to be a kernel bug.

    2) The fallback, ir-keytable -a, fails for 2 reasons:
    2.1) ir-keytable in LE was too old and didn't know about the RC5 streamzap protocol - the v4l-utils bump fixes this.
    2.2) even with the newer ir-keytable the streamzap keymap won't load because the protocol type "RC5_SZ" is invalid - that should be "rc-5-sz" instead.

    Simply speaking: in LE 7.0 the kernel setup your remote correctly, but in LE 7.95 that fails. ir-keytable also failed in LE 7.0 but that probably wasn't noticed before.

    I've just added another commit to the PR that fixes the illegal protocol in the file. That fix should be included in the next Milhouse build #0214. Please test if that works for you and report back.

    so long,

    Hias

    A very quick update before heading off to bed:

    I could reproduce the issues on Raspbian (kernel 4.9.9, kodi 17, probably any I2S soundcard that's an I2S slave) as well if I remove console=serial0 from cmdline.txt. Likewise adding that to the LE cmdline.txt prevents crashing.

    Just outputting sound via ALSA (eg running speaker-test -c 2 while kodi is setup for HDMI audio out) hasn't crashed so far.

    To crash the RPi0 we need no serial console (probably no serial device open at all) and kodi 17 switching audio out from HDMI to ALSA (short screen blank) and back to HDMI (hard crash).

    so long,

    Hias

    milhouse just tested with build 0211 and Justboom, same result (short blank screen when selecting audio device, crash when audio device was closed).

    Then I did another test with the Cirrus card instead of the Justboom, in this case it worked.

    Might sound odd, but an educated guess leads me to the conclusion something odd might be going with the kernel clock framework:

    Justboom DAC is configured as an I2S slave (RPi configures it's internal clocks), Cirrus is an I2S master (it drives the I2S clock and the RPi I2S driver skips changing the RPi clocks).

    Screen glitches when changing the RPi clocks have been reported before, and if the clocks are configured wrong (eg turned off completely) lockups can happen as well.

    Now to find out what exactly is happening, and why it only happens with the LE kernel not the official one. I guess we need Dom's and Phil's help.

    BTW: I could be wrong, this is just an educated guess.

    so long,

    Hias

    Can you try a clean install of 7.95.3 on a separate SD card and see if this works?

    Do you have any local config/settings installed in /storage/.config/udev.rules.d, /storage/.config/rc_keymaps or autostart.sh? If yes, remove them, they could be interfering.

    Also please post the output of these 2 commands on your non-working setup (without your ir-keytable in autostart):

    Code
    dmesg | paste
    ir-keytable -v -a /etc/rc_maps.cfg -s rc0 2>&1 | paste

    so long,

    Hias

    Could you try setting the audio configuration to Fixed, for example 96kHz and see if you still get clicks?

    The driver for the WM5102 soundchip (which comes from the upstream linux kernel) is designed to be run at a fixed internal clock rate which is a multiple of the samplerate. This means it can support 32kHz, 48kHz, 96kHz, 192kHz (or 44.1, 88.2, 176.4kHz) without needing to change the internal clock. But switching between these 2 families, eg from 44.1kHz to 48kHz is tricky: the internal clock needs to be reconfigured which can cause glitches.

    Muting the outputs is also a little bit tricky and the S/PDIF output doesn't have a mute setting at all - so it's not really easy to mute all outputs.

    So, I'm aware of possible problems but currently don't have a solution for that that'd work for all configurations.

    I have to add that I've been using the card with S/PDIF-out and Line-out and so far didn't experience any loud clicks yet.

    so long,

    Hias