Can I bring back old approach with remote.conf from LE 8 without need to recompile image?
No, this stuff is gone for good. AML now uses the same method to support IR remotes as all other platforms.
so long,
Hias
Can I bring back old approach with remote.conf from LE 8 without need to recompile image?
No, this stuff is gone for good. AML now uses the same method to support IR remotes as all other platforms.
so long,
Hias
I am still confused with that. In general, no lags but if (for example) I keep pressing Down button very quickly, 1 of 3 events are lost.
This is caused by a combination of using remotes with the NEC protocol (which doesn't have a flag if it's a new button press) in combination with the old 3.14 kernel (which is missing the IR optimizations found in current linux kernels).
You can get better remote response by running
Just add it to autostart.sh (you can test with lower values, down to 10000-20000 as well)
so long,
Hias
Best stick to the kodi button names in the devinput section of Lircmap.xml and use the keycodes that are mapped to kodi buttons (eg KEY_INFO, KEY_MENU, KEY_FORWARD, KEY_REWIND, ...).
A full list of kodi button names is in the IRTranslator source file irtranslator.cpp#l164-l229
As explained in the Kodi wiki LIRC - Official Kodi Wiki remote button mapping is a two-step process. First Lircmap.xml maps a KEY_xxx code to a kodi button name and then you assign actions to kodi buttons in remote.xml
so long,
Hias
What kind of remote are you using and did you create the IR keymap file by yourself?
If you create an IR keymap it's best to stick to the keycodes that are usually found on remotes (see eg the rc6_mce keymap of the Microsoft MCE remote) as these will work out-of-the-box in kodi. More details are in the wiki Infrared Remotes [LibreELEC.wiki]
If you are using an RF remote it's not using the ir-keytable configuration discussed in this thread - in this case please open a separate thread.
so long,
Hias
Remote input is handled differently than keyboard input.
Kernel input events from remotes are translated to lirc events by eventlircd, then received by kodi as lirc events and run through the Lircmap.xml -> translations in Kodi and are finally mapped by <remote> blocks in keyboard.xml files.
so long,
Hias
Thanks a lot for testing!
It'd be best to contact Matt Flax (who created the card and wrote the driver) and tell him that the driver doesn't work on kernel 4.19. He can then submit the required changes to the RPi kernel where we will pick them up.
Opening an issue on RPi kernel github would be another possibility, but as probably only Matt has the hardware and knows what to change contacting him directly would probably be easier/quicker.
so long,
Hias
Could you check if the card works in Raspbian with kernel 4.19?
First install Raspbian Stretch and add the soundcard config, the card should be detected.
Then run the following command to switch to kernel 4.19
Then reboot and check if the card is still detected.
The LibreELEC kernel config looks fine (all drivers should be there) but IIRC the Audioinjector Octo driver was dropped for some time in kernel 4.19 because it didn't compile - maybe the driver isn't fully working yet in kernel 4.19.
so long,
Hias
In general I2S soundcards should work fine, but I'm not familiar with the audioinjector octo card.
Can you please post the full dmesg and vcdbg log msg output?
You seem to have dtparam=audio=on in config.txt, drop that, it's not needed. Also not sure why you have spi=on and i2c_arm=on in config.txt- the devicetree overlay should enable all components so in general it's enough to add the dtoverlay line.
so long,
Hias
Thanks for testing and the feedback!
Quite certainly the chinese manufacturer choose some odd audio setup/configuration that isn't supported in Linux. So using a USB soundcard is probably the easiest option.
Some time ago I bought a cheap PCM2704 based USB audio adapter on ebay (approx. 5 EUR shipped from china), which works out of the box in Linux and Kodi. Build quality is about what you'd expect for the price but it has both analog and digital (coax and toslink) outputs and does it's job.
so long,
Hias
I still suspect it's an audio driver or firmware issue.
Kodi should be fine, it's the same 18.0rc3 version as in the current LE beta and except for a bunch of errors because the baytrail audio device doesn't support surround the kodi log looks fine (at least for opening the audio device).
One difference between kodi and speaker-test though is that kodi outputs audio in 24bit format whereas speaker-test uses 16bit.
An interesting test would be playing a 24bit 48kHz stereo WAV file with aplay. If there's a driver / firmware bug it should give the same (or similar) distortions as kodi.
Can you also test the ssp0 and windows driver firmware files and the amixer settings as I outlined before?
so long,
Hias
My espresso machine stopped working due a signal [1011] ☺
This probably means "out of coffee" ![]()
Merry Christmas,
Hias
I'm using berryboot
Don't do that, berryboot is causing exactly the issues you are seeing by swapping out LibreELEC's linux kernel with it's own - which is probably missing the driver or some patches.
LibreELEC 8.2.5 and current LibreELEC 9.0 alpha releases support the DVB dongle out of the box on RPi, without needing to enable any DVB drivers or other stuff.
Just install LibreELEC directly to an SD card, without using berryboot, or use NOOBS/PINN if you want to have a multi-boot setup.
so long,
Hias
If you don't get any video at all then GPIU memory may be too small. Increasing it from 256 to 320MB should help
You only need to overclock if videos stutter. But keep in mind that you'll need proper cooling, otherwise things could be worse than before.
I'm using these settings on two of my RPi3B+
Will there ever be a working Netflix Addon for RasPi?
so long,
Hias
Kodi supports an EjectTray() function, see List of built-in functions - Official Kodi Wiki which is mapped for (infrared) remotes, but not for keyboards.
The easiest solution is to manually create a .kodi/userdata/keymaps/keyboard.xml file with the appropriate config. eg something like this:to eject the tray when you press e
Instead of <e>EjectTray()</e> you can also specify keycodes via eg <key id="123">EjectTray()</key> - see the kodi keymap wiki page for details Keymap - Official Kodi Wiki
so long,
Hias
Thanks for the feedback! Getting "something" out indeed is a bit of a progress ![]()
Out of curiosity: what do these "beeps" sound like? speaker-test -t sine should output a 440Hz sine alternating on left and right channels.
Baytrail audio seems to be a really deep rabbit hole and I'm a bit running out of ideas. Testing different firnwares and trying a few other settings look worthwihile though - although these are just (educated) guesses.
The driver loads the firmware from `intel/fw_sst_0f28.bin`, so you can create a .config/firmware/intel directory and try with other firmware files - they have to be named `fw_sst_0f28.bin"` and stored in that directory. Just reboot after changing the file and it should be picked up (you can check with `ls -la /lib/firmware/intel/fw_sst_0f28.bin`, that should be a symlink pointing to /storage/.config/firmware/intel/fw_sst_0f28.bin).
One firmware to test would be /lib/firmware/intel/fw_sst_0f28_ssp0.bin, you can also try the realtek_fw_sst.bin from the windows driver (not idea though if that will work).
With the ssp0 firmware and maybe also with the realtek firmware you could try alternate config settings related to ssp0 firmwares - I noticed this in /usr/share/alsa/ucm/codecs/rt5640/EnableSeq.conf:
# uncomment to enable swap between AIF1 and AIF2
# warning: can only work with SSP0 firmware enabled
cset "name='SDI select' 0"
cset "name='DAI select' 0"
#cset "name='SDI select' 1"
#cset "name='DAI select' 1"
So after configuring the device with alsaucm try the following 2 commands, after that try speaker-test
You'll probably have to test all combinations of firmware and with/without these amixer commands, maybe some combination of these will succeed.
When searching the web for baytcr, rt5640 and fw_sst_0f28.bin I came across some (github) repos which had different fw_sst_0f28.bin firmware files for some devices (eg this one firmware/intel at master · Asus-T100/firmware · GitHub) - maybe one of these contain firmware matching your baytrail box.
so long,
Hias
Ah, sorry, I should have read the manpage more carefully - using 2 separate alsaucm calls doesn't work.
The end of the manpage gives an example how the Speaker device on baytrail can be selected - better use that as a template Ubuntu Manpage: alsaucm - ALSA Use Case Manager
Thanks for the logs! dmesg spam seems to be gone, but there are lots of Alsa errors in the kodi log. I think it's best to focus on getting speaker-test working.
I looked through the alsaucm docs and noticed I missed an important step: after setting the _verb we also need to enable the (output) device. The output devices "Headphones" and "Speaker" look like good candidates.
Please try these commands:
Then run speaker-test -c 2 -t sine again and upload dmesg.
If it didn't work try with the Speakers device - but before we need to disable the Headphones device
According to the manual using the "reset" command should also work, this should allow us to start from scratch:
alsaucm -c bytcr-rt5640 reset
alsaucm -c bytcr-rt5640 set _verb HiFi
alsaucm -c bytcr-rt5640 set _enadev Speaker
Try speaker-test again and grab dmesg.
If you get any errors on the terminal these would be interesting, too.
so long,
Hias