Posts by HiassofT

Quote from tomasz1500

Also one more question : did anybody notice that when we connect RPi2 and Wolfson, some of the 8 big pins from Wolfson make contact with elements on the Pi board ? Is it supposed to be like this? I put some tape there not to short anything.

This sounds like you are trying to use the original Wolfson card for the RPi1 (with 26 pin GPIO connector plus 8 pogo-pins for the P5 connetor). If that's the case - sorry, that won't work, you need to use the Cirrus card (with 40 pin GPIO and no pogo pins) on RPi2 (and all other B+ models with 40-pin GPIO connector).

so long,

Hias

JustBoom it's the same for Kodi running under Raspbian (and probably OSMC as well), passthrough is only available if the soundcard provides an iec958 pcm (check with aplay -L).

Testing with Raspbian might be easiest for you (just adapt the conf file and store it in /usr/share/alsa/cards). If you have a working conf file drop us a line and we can include it in LibreELEC.

BTW: for the Hifiberry Digi we had to add a .driver_name to the kernel driver, otherwise ALSA would not have been able to distinguish between Hifiberry DAC (analog card) and Digi (SPDIF card).
linux/hifiberry_digi.c at rpi-4.9.y · raspberrypi/linux · GitHub

If no .driver_name is present ALSA falls back to using .name with underscores removed and truncated to 15 characters - which is too short if .name is snd_rpi_hifiberry_digi. You probably need to do the same for your justboom Digi/Dac drivers.

so long,

Hias

Hi Eric!

I've run into a similar issue during testing, the problem most certainly comes from the Krypton Confluence skin not really working with Jarvis. You could try uninstalling the Confluence addon, then the built-in Confluence skin should be used.

But there may have been other (newer, possibly incompatible) addons installed and you'll have newer database versions (which might cause troubles when you later update to Krypton) so it'd be better to do a soft or hard reset.

BTW: If you used the integrated update feature you'll most certainly be using the official LibreELEC versions, not my builds - check in the system info, my build should show up as "LibreELEC (HiassofT)" instead of "LibreELEC (official)". In that case better post in the Bug Reports forum.

so long,

Hias

Quote from e01_03m

Im a end user and I just updated to 7.0.3 but now I can not update to another version.
I use kodi jaris 16.1 on raspberry pi3

Have you update to the official 7.0.3 build or to the one linked from this forum topic? To which version are you trying to update to, which steps did you take to update and what exactly is happening?

so long,

Hias

Hi John,

thanks a lot for the feedback!

I haven't decided yet on 8.0 (beta) releases. I've got an 8.0 LE tree working here with the new driver, but IMO kodi 17 isn't quite ready for everyday use yet so I decided to release a 7.0 build with the new driver first and see how that goes.

so long,

Hias

I've been working on a major driver rework, removing the need to add a ton of patches to upstream Linux code, fixing several outstanding issues and adding some new features.

Here are builds based on LibreELEC 7.0.3:
RPi: LibreELEC-RPi.arm-7.0.3-HiassofT.tar
RPi2/3: LibreELEC-RPi2.arm-7.0.3-HiassofT.tar
Source code: GitHub - HiassofT/LibreELEC.tv at 7.0.3-cirrus-ng

Note: the name of the soundcard has changed from "snd_rpi_wsp" to "RPi-Cirrus".

One of the new features is proper AC3/DTS passthrough support via S/PDIF, including setting the S/PDIF channel status bits. Choose "RPi-Cirrus, S/PDIF" for that, this device will mute all other analog outputs.

To use the analog outputs (plus S/PDIF) choose "RPi-Cirrus Analog" - this works as before in the previous versions and you can customize the mixer routing (mixing line-in into the signal etc).

Customizing the mixer settings is now done via a shell script (instead of the udev rule):

Use .config/rpi-cirrus-config.sh.sample as a template. This scripts makes use of a bunch of helper functions and definitons in /usr/lib/alsa/rpi-cirrus-functions.sh to simplify setup - you can either use these functions or simply add amixer statements as before (but note that you need to change the soundcard name).

Note: These builds use the rather new Linux kernel 4.9. The current LibreELEC alpha builds also use this kernel but it's still possible that there are some (yet unknown) issues. Just drop me a line if something doesn't quite work as excpected.

so long,

Hias

This script is only run during bootup. After that you'll get any signal that's present on LineIn to your speaker - if your TV (I assume lineout of the TV is connected to linein on the Cirrus card) outputs a transient on powerup/down you'll hear that - not nice.

There's not much we can do to avoid this, except manually muting the signal or manually switching between "output kodi sound" and "output line-in sound".

You could do that with the help of some external shell scripts (with mixer settings) that you then call from kodi - for example mapped to some buttons on your keyboard or remote.

Calling a shell script from within kodi is a little bit tricky, System.exec doesn't work as expected (it messes up AudioEngine), you have to use Runscript to call a python script which then can use os.system to run the shell script. Look here for more info: LibreELEC

so long,

Hias

Quote from avkhid

There is one small problem outstanding; every time I switch on TV on switch the inputs, there is a loud switching noise (like popping or sharp loud tick sound). This only happens during switching. I tried 'Speaker Digital Switch' off, but the noise is still there. Any ways to mute that?

When did you try the Speaker Digital Switch off setting? Right before switching on the TV?

The "Speaker Digital Switch" control is the mute-control for the Speaker output. If it's set to off you shouldn't get anything on speaker output.

so long,

Hias

Hi Vijay!

Your listen script contains DOS lineendings (CR+LF), change that to unix EOL style (LF only). Ah, and better use #!/bin/sh instead of #!/bin/bash.

You also have to reorder the scripts in the udev file, currently Playback_to_Speakers runs after your Listen scripts and resets the Input 2 settings.

It's best to merge that into 1 single file, setup Input 1 to AIF1RX1/2 and Input 2 to IN3L/R

so long,

Hias

Have a look at the Listen_to_LineIn_on_Speakers.sh script as an example of how this can be configured. But note you can't use that script out of the box, it also uses Input 1 of the speaker output mixer (same as the playback to speaker script).

It's best to copy the Playback_to_Speakers.sh script to the storage partition, let's say /storage/speaker-setup.sh and make some alterations. You probably also want to change the volumes of Kodi audio output, the signal received on line-in and the speaker output volume.

First, route the line-in signal (IN3L/IN3R) to the second input of speaker out, using the default input gain of 0dB (input volume 32)

There are several knobs to turn to control the volume. Let's go input-to-output:

"IN3L Volume"/"IN3R Volume" control the analog input gain (before the ADC). Default is 0 (0dB), 1 is +1dB etc. Usually values between 0 and 8 should be OK (depending on the analog signal level).

"IN3L Digital Volume"/"IN3R Digital Volume" control the gain in the digital domain (after the ADC). Usually it's best to keep that at the default 128 which means 0dB (i.e. no volume change).

"SPKOUTL Input 2 Volume"/"SPKOUTR Input 2 Volume" set the output mixer level. Default is 32 which again means 0dB (31 is -1dB, 33 +1dB etc). Adjust these and also the "SPKOUTL/R Input 1 Volume" (RPi/Kodi volume) settings so that the line-in signal and kodi signal are about the same level. But be careful: if you set it above 32 the signal might clip (especially for Kodi output).

"Speaker Digital Volume" sets the speaker output volume, that's your "master volume knob". Default is 128 / 0dB, 127 is -0.5dB etc. Again, better only use values lower or equal to 128 to attenuate the signal, values above 128 may cause clipping.

so long,

Hias

Quote from avkhid

Thanks for your response and a good observation. However, that line was from the terminal output when I tried running "Listen_to_SPDIF_on_Speakers.sh" from putty. In the file itself, it has quotation marks as follows.

amixer ${BEQUIET} -D${CARD} cset name='TX Playback Switch' off

Those listen scripts were written for a rather old version of the driver, "TX Playback Switch" doesn't exist in the current version.

If you already set up speaker output (i.e. run "Playback_to_Speakers.sh) you can mix in SPDIF in via these commands (using the second of 4 inputs, the first one is used for standard playback output from RPi):

But all this probably won't work as you'd expect, there are some nasty details to keep in mind when using SPDIF input:

The card has to be set up to the same sampling rate as the signal on the SPDIF input. Setting the card to 44.1kHz and trying to receive a 48kHz signal, for example, doesn't work. So you have to make sure the SPDIF sampling rate is fixed and then configure kodi to only use that rate - in this case it can work.

When you are using SPDIF input the sound card locks onto the SPDIF signal and uses that as it's clock source instead of it's internal oscillator. So when there's no SPDIF input signal present or the card can't lock onto it (eg wrong samplingrate) you'll get no or only distorted output.

You'd be better off using one of the analog inputs instead, they don't suffer from any of these limitations.

so long,

Hias

There's also System.Exec, using that to run a shell script without arguments seems to work fine but it seems it still causes the AudioEngine Error in kodi.log (tested with LE 7.0.2, not sure about alpha versions / krypton).

As posted on the kodi forum we need more info from you:

Quote

Could you post some more details? What kind of IR receiver and remote are you using? How did you start irrecord? What did irrecord show at the start (you should see something like "Using driver default on device /dev/lirc0")?

I've just tested with build 0719 on a RPi1, recorded some 20 keys of my Hauppauge remote using lirc_rpi and it worked fine. irrecord started with "irrecord --device /dev/lirc0 --driver default"

It would also help if you uploaded the working lircd.conf file generated by 0.9.0 irrecord and the non-working one generated by 0.9.4 irrecord - plus the info which remote was used.

so long,

Hias

The PCB looks like an I2C adapter for hd44780 LCDs/VFDs. I did some tests with one of these (might have been a different one than yours) some 2 years ago on OE and software-wise it worked out of the box with LCDproc - just some config is needed.

Off the top of my head:

• add dtparam=i2c=on to /boot/config.txt to enable the I2C support
• install the lcdproc addon and configure it to use the HD44780 driver
• copy /etc/LCDd.conf to /storage/.config/LCDd.conf and change the hd44780 section to use I2C

I found a backup of the LCDd.conf on my HDD, the hd44780 section of it looks like this (you may need to change the port to match the I2C address of your adapter board):

I remember having to do some electrical modifications to the adapter board (these may or may not apply to your board). IIRC the LCD connector pinout/I2C extender connections were different to what lcdproc expected them to be and I had to modify the board to use 3.3V for I2C (it was built for 5V).

so long,

Hias

Quote from Cbprado

QIcN
FFJS

The HD isn't formatted FAT but HFS+ with journalling:

You either have to disable the journal (there should be some option to do that on a mac) or format the HD in ext4, FAT or NTFS.

so long,

Hias

Ive just uploaded new builds - based on the LibreELEC 7.0.2 release - to my website

Here are direct links to the builds:

7.0.2 build for original RPi
7.0.2 build for RPi2/3

Changes since 7.0.1 build:
- Drop local I2S/DMA fixes, these issues have been fixed in the RPi kernel

so long,

Hias

Quote from uselibreelec

While holding down a remote control button (UP or DOWN for example), the the keypress gets not repeated, so you have to do scrolling (for example) row by row, one button press at a time.

Could you please upload kodi debug logs, both of a build which has that issue (eg a recent milhouse build) and your working (kernel 4.4) build?

Also please post some details about your setup. Which modules are loaded (both working and non-working), are you using userspace lircd (i.e. manual setup via lircd.conf), any other settings/options/config-files you had to change?

so long,

Hias

Quote from ReiniB

Code

1. journalctl -a | grep udevd

no effect with the code

Crap, that's a bug in LE (it already rotated away the important log entries) - I've reported it here:
LibreELEC

But there's another method we can use and even get more info on what might be failing with the udev rule.

First we tell udevd to output debug messages as well:

Then simulate a change event for the sound subsystem, this causes the 90-wolfson.rules file to be run again:

Now check the system log, do a "journalctl -a | grep udev". If you mistyped the script filename you should get an error message like this:

If you can't figure out what's going on just upload the whole journalctl output to a paste site and I'll have a look at it:

If you spotted the error and corrected the 90-wolfson.rules file you first have to tell udevd about the change, then you can trigger the change again. So, after editing run these 2 commands:

Then look at the journalctl output for any errors until you got it working.

Quote

agree, but executing script between switching is no option.

I meant that you should try to add these lines at the very beginning/end of the listen script - before the first "amixer" line and after the "fi" at the very end.

Quote

The scripts for using the inputs with the DSP aren't of help aswell for me and I'm getting tired to look for sources with suitable informations. Any suggestions (pics + samples ) for absolute beginners?
Thanks for now, for you patience and your help,

What do you mean with DSP? The wm5102 has a DSP inside which could indeed be used for very interesting stuff. But unfortunately the tools to create the DSP code aren't publically available so we can't use that

Or do you mean the integrated equalizer/mixing/... functionality? The mixer is documented fairly well in the datasheet and there's some further info about the equalizers available as well in the discussions on the element14 forum. But, yes, this is rather advanced stuff

so long,

Hias