Posts by apokalypz

I know I'm grave digging, but I couldn't find a newer post with this problem where the last button press registers again with a new button press, effectively doubling every keypress.

It looks like mainline has fixed the issue:

media: rc: meson-ir: add timeout on idle · torvalds/linux@8d7a77c · GitHub

They, fittingly, call these keypresses "ghost" keypresses. It looks to be caused by the hardware not generating a timeout after each keypress, so they added it in software.

My question is this:

Can we get this fix backported to our kernel in the official odroid C2 (and generic amlogic devices) builds?

Thanx

I have libreelec alpha 7.90 on my odroid-C2 with the odroid bluetooth dongle connected to my Bluetooth headset. When it sends audio to the headset I hear a lot of background noise/static as if the gain was up too high. But my headset doesn't have a gain control or A/V buttons for remote volume control. If I lower the volume using KODI or pulseaudio's command line tool, it doesn't lower the background noise, it just lowers the volume of sounds that come from KODI.

I tried a couple headsets and they all have this issue. I also tried connecting my headsets to my android phone to see if I get the same problem with android, and my findings were interesting. Initially when connected, the background noise was there, however when I adjusted the volume on my phone, the noise faded to acceptable levels.

I believe the problem is in how the volume is being controlled, or more specifically, in what part of the process the volume is controlled. It seems Android controls the volume at the end-point in the headset, whereas KODI/Pulseaudio only controls the volume of the stream mix going into the Bluetooth connection, putting the actual headset device at maximum volume all the time.I don't really know where to look to fix this. I tried messing around with bluetoothctl to no avail.

Does anyone know of a way to fix this (by using libreelec to control the volume of the actual headset)?

Not sure if this really is a bug/oversight or is intentional (maybe it doesn't work while enabling NEON?), but at the top of the KODI log it says:

06:20:11.779 T:547591626752  NOTICE: ARM Features: Neon disabled

Not that enabling NEON in the KODI build would noticeably improve performance, wouldn't enabling it be better than not enabling it?

EDIT: Upon doing more digging, I ran across a merged PR from a month ago that kind of explains why neon is disabled. Here is a couple commented lines that were included in the change from the PR:

# change this to --enable-neon when AArch64 NEON performance is improved
		+  # check performance with test/benchbitslice

It seems to suggest NEON introduces a performance regression when enabled.