Posts by HiassofT


    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):

    Code
    amixer cset name="SPKOUTL Input 2' AIF2RX1
    amixer cset name="SPKOUTL Input 2 Volume' 32
    amixer cset name="SPKOUTR Input 2' AIF2RX2
    amixer cset name="SPKOUTR Input 2 Volume' 32

    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):

    Code
    [hd44780]
    ConnectionType=i2c
    Device=/dev/i2c-1
    Port=0x27
    Backlight=yes
    Size=20x4
    DelayBus=true
    DelayMult=1
    Keypad=no

    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


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

    Code
    /dev/sda2 on /var/media/Filmes type hfsplus (ro,nosuid,nodev,noexec,noatime,umask=22,uid=0,gid=0,nls=utf8)
    Code
    [ 8.425261] hfsplus: write access to a journaled filesystem is not supported, use the force option at your own risk, mounting read-only.


    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


    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

    Code
    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:

    Code
    udevadm control --log-priority=debug


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

    Code
    udevadm trigger -s sound


    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:

    Code
    LibreELEC systemd-udevd[1584]: failed to execute '/this/is/a/wrong/path' '/this/is/a/wrong/path': No such file or directory

    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:

    Code
    journalctl -a | paste

    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:

    Code
    udevadm control --reload
    udevadm trigger -s sound

    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


    Is what you are looking for in dmesg?

    Not dmesg, but the system log (journal). I'm looking for error messages from systemd-udevd.

    A user reported that his udev rule doesn't work as expected, so I told him to do a "journalctl -a | grep udev". When I posted that (on May 17th) it worked on my system and I could see error messages like this:

    Code
    LibreELEC systemd-udevd[1584]: failed to execute '/this/is/a/wrong/path' '/this/is/a/wrong/path': No such file or directory

    But when he reported back yesterday he wrote that "journalctl -a | grep udev" didn't have any effect LibreELEC and I could verify that on my system.

    The same thing happens on Wetek Play BTW and I guess all systems without an RTC are affected. XSXT

    This is really annoying because without the system/boot log it's next to impossiible to track down errors

    I think it would be best to disable time based rotation in journal.conf and only have size limits (the journal.conf manpage also suggests to do that) because we can't rely on the system time being set correctly on boot.

    so long,

    Hias
    [hr]
    Did a quick test, MaxRetentionSec indeed seems to be the culprit. If it's commented out in journald.conf (i.e. stock systemd config, default to none/unset) the journal output is back to what it should be:
    HBXd

    so long,

    Hias

    While trying to trace down some udev issues on RPi (3), running LE 7.0.1, I noticed that all of the boot messages where missing in the journal - journalctl -a started way too late.

    Code
    -- Logs begin at Mon 2016-06-20 23:13:32 CEST, end at Mon 2016-06-20 23:14:49 CEST. --
    May 18 14:51:06 LibreELEC connmand[385]: ntp: time slew +2881345.749678 s
    Jun 20 23:13:32 LibreELEC systemd[1]: Time has been changed


    The full log is here: ZECJ

    To me it looks like the following might have happened:
    - systemd noticed that the day was way back (there's no RTC on RPi), so it set the current date to it's build date (May 18th). From dmesg:

    Code
    [    2.545925] systemd[1]: System time before build time, advancing clock.


    - journald started, collected boot messages etc
    - correct date was received via ntp, journald noticed that, rotated the journal because it's now June 20th and in journal.conf there's #MaxFileSec=1month (default) and then discarded the journal because of MaxRetentionSec=1day (explicitly set in journal.conf)

    It would be great if some systemd/journald expert could have a closer look into that, maybe I missed something, but it seems we can't trace issues via journalctl on builds older than a month...

    so long,

    Hias


    wow, thank you, first time to have an effect...

    ...but just in testing. It doesn't work permanentely as you described. Wrong path?


    You probably have a typo or some error in the udev rules file, check for that in the system log:

    Code
    journalctl -a | grep udevd


    Quote


    P.S. Next issue: How to avoid the 2 plop noises during switch between the inputs without setting the volume to 0 / by setting the volume to 50 in Row 12 + 13 in Listen_to_LineIn_on_Lineout.sh ? (Plop noise is getting louder by increasing the value)


    You could try muting the output before changing the settings and unmuting it afterwards:

    Code
    amixer cset name='HPOUT2 Digital Switch' off
    ...
    amixer cset name='HPOUT2 Digital Switch' on

    so long,

    Hias
    [hr]


    Hello again, here are both pastebins after trying to play an ogg


    Thanks for the logs!

    The soundcard seems to be detected fine, but this line in dmesg is very suspicious:

    Code
    bcm2835-dma 3f007000.dma: DMA transfer could not be terminated

    I've seen that, too, if the card was unconfigured, eg if you have some error in the udev rule file (are you sure you didn't change that)? In that case I also get the "snd_pcm_writei returned -5" errors in kodi.log.

    Just remove the udev file and reboot (then it'll be recreated with default contents). It might need a second reboot for the change to take effect.

    Code
    rm /storage/.config/udev.rules.d/90-wolfson.rules
    reboot

    If it still doesn't work please upload the system log

    Code
    journalctl -a | paste

    so long,

    Hias


    sorry, I`m a complete newbee:
    1. Where lives the mixer setting to modify? In the Listen_to_SPDIF_on_LineOut.sh ?


    Yes, exactly.

    BTW: Just noticed that I had already uploaded fixed versions of the scripts to my website:
    listen-scripts.tgz

    Just use these and you don't have to change the stuff yourself

    Quote


    2. Where to store the listen files to let them execute from

    Code
    90-wolfson.rules

    For simplicity just copy the listen script directly into /storage/ - eg /storage/Listen_to_LineIn_on_Lineout.sh

    For testing run the script from a terminal, edit it, run it again... until you are happy with the result.

    Then, if you want to make it permanent (i.e. automatically activated at each boot) add it to the 90-wolfson.rules file. It should look somthing like this:

    Code
    # enable SPDIF plus all analog outputs
    SUBSYSTEM=="sound", ACTION=="add|change", ATTR{id}=="sndrpiwsp", \
    RUN+="/usr/bin/SPDIF_playback.sh -q", \
    RUN+="/usr/bin/Playback_to_Lineout.sh -q", \
    RUN+="/usr/bin/Playback_to_Headset.sh -q", \
    RUN+="/usr/bin/Playback_to_Speakers.sh -q", \
    RUN+="/storage/Listen_to_LineIn_on_Lineout.sh eq"

    so long,

    Hias

    Hi ReiniB!


    My target is to have a 2nd. input source on the line-out like described at "Listen_to_SPDIF_on_LineOut.sh" from Ragnar Jensen with the abillity to tune a bit at the equalizer. Are there any options to get some examples (step-by-step) or to read about getting the scripts to work in LibreELEC or a basic education about the audio-in options?


    The Record-... scripts are for setting up recording (eg when using arecord), these are of no much use with LibreELEC/Kodi. The listen scripts are what you need.

    There are 2 gotchas when using SPDIF:

    First the easy to solve one: You have to slightly modify the mixer settings and change "SPDIF in Switch" to "SPDIF In Switch" and "SPDIF out Switch" to "SPDIF Out Switch" (note the capital "I" and "O" in "In"/"Out").

    But the next one is tough: If you want to use SPDIF in you have to manually configure the card to the correct rate. If you only use 44.1kHz audio on SPDIF you could change the Kodi audio settings to only use 44.1kHz - when playing video or audio file Kodi the will resample everything to 44.1kHz. Likewise, if you want to use 48kHz audio on SPDIF set Kodi to 48kHz.

    If the configured rate doesn't match the rate of the SPDIF signal you'll end up in a mess: The audio chip tries to adjust the configured rate (eg 44.1kHz) to the one on SPDIF in (eg 48kHz) and usually fails miserably - that feature is intended to adjust for slight variations in clock speed (eg 44105 Hz instead of 44100).

    So mixing the SPDIF input signal into the output is very limited and might not work as expected if the SPDIF samplerate varies.

    Mixing the analog inputs (Line In, DMIC, Headphone in) into the output is a lot more practical:

    You don't have the samplerate restriction here, Kodi can choose whatever samplerate it likes and the soundchip just uses that one to digitize the analog signal and mix it with the output.

    I'd suggest you try the "Listen_to_LineIn_on_Lineout.sh" script, that should work out of the box and produce the expected result.

    If you start it with "eq" as a parameter it'll set up some equalizer settings as well.

    Just play around with the "EQ...Volume" settings in the script and adjust them to your likes. You can find more background info in the linked discussions on my website.

    so long,

    Hias

    I'm using a simple IR receiver hooked up to the GPIO of my RPi and it's working just fine - both with the lirc_rpi driver plus userspace lircd and with the in-kernel gpio-ir-reciever driver from the rc framework (which doesn't need userspace lircd). But I couldn't get the longpress keyboard/remote modifier in kodi keymaps working.

    For testing I used a very simple remote.xml - long-pressing left should do a right and vice versa:

    In a standard setup (eventlircd running, picking up the input events from user/kernel-space lirc and relaying them to kodi via the lirc socket) the kodi log looks quite funny. First a short press then a long press:

    Code
    13:06:45 447.539246 T:1962627072   DEBUG: LIRC: Update - NEW at 69863:69 0 KEY_LEFT devinput (KEY_LEFT)
    13:06:45 447.539459 T:1962627072   DEBUG: OnKey: 169 (0xa9) pressed, action is Right
    13:06:45 447.799103 T:1962627072   DEBUG: LIRC: Update - NEW at 70122:69 0 KEY_LEFT_UP devinput (KEY_LEFT_UP)
    
    
    13:06:50 452.380463 T:1962627072   DEBUG: LIRC: Update - NEW at 74704:69 0 KEY_LEFT devinput (KEY_LEFT)
    13:06:50 452.380676 T:1962627072   DEBUG: OnKey: 169 (0xa9) pressed, action is Right
    13:06:52 454.378815 T:1962627072   DEBUG: Previous line repeats 28 times.
    13:06:52 454.378906 T:1962627072   DEBUG: LIRC: Update - NEW at 76702:69 0 KEY_LEFT_UP devinput (KEY_LEFT_UP)


    Note that in both cases the KEY_LEFT was translated to "Right". It looks like the longpress modifier in the remote section was ignored.

    With eventlircd stopped and kodi picking up the input events from lircd/kernel (handled as keyboard input) it looks as expected:

    Code
    13:16:31 1033.300049 T:1962508288   DEBUG: Keyboard: scancode: 0x69, sym: 0x0114, unicode: 0x0000, modifier: 0x0
    13:16:31 1033.579834 T:1962508288   DEBUG: OnKey: left (0xf082) pressed, action is Left
    
    
    13:16:35 1037.757080 T:1962508288   DEBUG: Keyboard: scancode: 0x69, sym: 0x0114, unicode: 0x0000, modifier: 0x0
    13:16:36 1038.136719 T:1962508288   DEBUG: Previous line repeats 2 times.
    13:16:36 1038.136841 T:1962508288   DEBUG: OnKey: long-left (0x100f082) pressed, action is Right
    13:16:36 1038.216309 T:1962508288   DEBUG: Keyboard: scancode: 0x69, sym: 0x0114, unicode: 0x0000, modifier: 0x0


    Short and long presses are detected and the correct action is performed.

    Now I'm wondering what I'm missing.

    Is longpress support with LIRC supposed to work at the kodi side? Eventlircd would generate _UP events but are they handled in kodi? Do I need some config setting or some special lircmap configuration for that?

    Or is longpress support only available on keyboard/input devices and eventlircd is the culprit?

    so long,

    Hias


    Thanks Hias the update did the job.

    It's reproducable. I did a fresh install on another SD card, there was no overlay foler.
    Updated it and there was the overlay folder including the overlays for Hifiberry.


    Thanks for the feedback!

    If it's reproducible could you please do a fresh installation and then list the contents of flash ("ls -lR /flash | paste")? Would be interesting to know what exactly is going on there. The directory listing might give a clue.

    so long,

    Hias