Posts by HiassofT

  • LibreELEC 8.0.0 build with Wolfson/Cirrus Logic audio card drivers

    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

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    Quote from JohnnyL


    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

  • Streamzap Remote not working on 7.95.3 Update

    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

  • JustBoom DAC Zero

    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

  • JustBoom DAC Zero

    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

  • MCE missing IR Protocols

    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

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    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

  • JustBoom DAC Zero

    Something really odd is going on with the RPi0. I haven't soldered on the GPIO connector so I did a quick test with dtoverlay=rpi-dac (this will work even without a soundcard installed) and could reproduce the issue with the 7.95.2 build:

    When selecting the ALSA soundcard in settings my monitor went blank for a very short time, then came back immediately. GUI and ssh were still working.

    Then (maybe when the sounddevice was closed after the 1min idle time, didn't time it) the screen went completely black.

    Still, ssh working fine and nothing in dmesg or kodi log (didn't have kodi debug logging active though).

    At this point I tried running "tvservice -s" and it just locked up. Same with "vcdbg log msg". Seems like the GPU has crashed.

    I thought maybe it had something to do with GPU resampling so rebooted and disabled it in audio settings. Then, when changing audio device from ALSA to HDMI the screen went black and the RPi crashed (ssh down).

    Pulled the plug, kodi came up with ALSA audio and software resampling. Changing audio to HDMI crashed the RPi0 again.

    so long,

    Hias

  • LibreELEC 7.0.3 build with new, reworked Wolfson/Cirrus driver

    Quote from tomasz1500


    One more problem - I get loud clicks between tracks when playing some albums on Tidal, or changing youtube videos..
    My speakers are pretty loud, but I think there should beno clicks at all.
    Is there a fix for this?
    I tried to set the option 'keep audio device alive' to 'always' , but no difference


    Do you also get these clicks when playing local music files?

    So far I haven't noticed these. There'll be a quite faint click when the audio card is turned off after the default 1min idle time, but that was it.

    You could try changing the resampling quality in system settings->audio (make sure you are in "Advanced" or "Expert" mode) an see if that makes a difference. And/or try changing the output configuration to fixed.

    Last but not least it could also be a problem with the audio/video tracks you are playing.

    so long,

    Hias

  • Problem with vdr.backend and IR GPIO

    This sounds a lot like this well known issue: lirc_rpi is sensitive to interrupt latency · Issue #906 · raspberrypi/linux · GitHub Unfortunately there's not much we can do about it.

    Since you seem to have an IR receiver integrated on your DVB receiver I'd recommend using that, ideally with the remote that came with it.

    You can use other remotes as well if they use the rc-5 protocol - for example a hauppauge remote should work. In this case you'll have to load the ir-keytable manually, eg with a "ir-keytable -w /usr/lib/udev/rc_keymaps/hauppauge" in autostart.sh

    so long,

    Hias

  • IR-KEYTABLE without LIRC / LIRCD

    Using ir-keytable on LE is rather simple: just drop your keymap in .config/rc_keymaps and it'll be automatically picked up by ir-keytable -a (run from standard udev rule).

    I'm doing this for about half a year now on RPi, have this line in config.txt

    Code
    dtoverlay=gpio-ir,gpio_pin=5,gpio_pull=1,rc-map-name=rc-hauppauge


    and placed a slightly modified hauppauge keymap in rc_keymap.

    If you've done this before it's a piece of cake on LE as well :)

    so long,

    Hias

  • IR remotes: eventlircd interfering with longpress support?

    Unfortunately not yet. Kodi still can't cope with a several linux input keycodes, eg KEY_OK, KEY_CHANNELUP etc, they all result in XBMCK_UNKNOWN.

    But there's a workaround: you can use a custom lircd.conf file (if you are using userspace lirc) or a custom rc-keymap (if you are using in-kernel decoding) and substitute the problematic keycodes with working ones (eg KEY_ENTER instead of KEY_OK). Then you can disable eventlircd, kodi will see the linux input events and long-press works.

    You'll also have to make sure the kodi http://remote.xml/keyboard.xml match the codes you are using, so that's mainly a solution for more experienced users.

    so long,

    Hias