LIRC / Tickets / #169 audio_alsa: LIRC returns previous remote key when pressing a new key

danitool - 2016-01-16

Sorry for the formatting, I paste again what happens with the remote

. <- key 9 pressed, nothing shown
00000000000005d2 00 KEY_9 rct3004 <- key 8 pressed
00000000000005ca 00 KEY_8 rct3004 <- key 7 pressed
00000000000005c2 00 KEY_7 rct3004 <- key 6 pressed
00000000000005d1 00 KEY_6 rct3004 <- key 5 pressed
00000000000005c9 00 KEY_5 rct3004 <- key 4 pressed continously
00000000000005c1 00 KEY_4 rct3004
00000000000005c1 01 KEY_4 rct3004
00000000000005c1 02 KEY_4 rct3004
00000000000005c1 03 KEY_4 rct3004
00000000000005c1 04 KEY_4 rct3004
00000000000005c1 05 KEY_4 rct3004
00000000000005c1 06 KEY_4 rct3004
00000000000005c1 00 KEY_4 rct3004 <- key 3 pressed
.....

Regards

Last edit: danitool 2016-01-16

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-17

hm... my gut feeling is that this might be about the audio driver which isn't the most used one. I guess that you are on some kind of specific hardware, but if possible: could you test with another capture device (and thus driver)?

If it's about the audio driver, the likely cause is some kind of copy-paste error when the statically linked driver was converted to a dynamic one. There has been one or two of those (one of which fixed in current master).

BTW: note that a similar issue was resolved, sort of, using another remote.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-01-17

I also made the tests using a different IR receiver, with a homebrew serial port receiver:

lirc 0.9.2a
homebrew serial: OK
audio_alsa: FAIL, it returns the previous code

lirc 0.9.3a
homebrew serial: OK
audio_alsa: FAIL, it returns the previous code

All tested on the same machine (x86_64) and same LIRC builds. Tested 2 different remotes.

In a totally different machine, I only tested the audio_alsa driver, and again it returns the previous code, but with the old lirc 0.9.0 it works quite fine. This happens with different remotes (I tested 2 or three).

Should I make tests with latest trunk revisions?
Or better, any specific change into the source code for testing instead?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-17

OK, let's assume it's about the audio driver. Furthermore, whatever happened with it, is is in the 0.9.0 .. 0.9.2a window. So the first check would be the 0.9.1a release - could you check that?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-01-17

Hi, the 0.9.1a release works OK

[dani@tool lircold]$ irw
00000000000005d2 00 KEY_9 rct3004 <- key 9 pressed
00000000000005d2 01 KEY_9 rct3004
00000000000005ca 00 KEY_8 rct3004 <- key 8 pressed
00000000000005c2 00 KEY_7 rct3004 <- key 7 pressed
00000000000005d1 00 KEY_6 rct3004 <- key 6 pressed
00000000000005d1 01 KEY_6 rct3004
00000000000005c9 00 KEY_5 rct3004 <- key 5 pressed
00000000000005c1 00 KEY_4 rct3004 <- key 4 pressed
00000000000005d0 00 KEY_3 rct3004 <- key 3 pressed
^C
[dani@tool lircold]$ lircd -v
lircmd 0.9.1a

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-17

OK. It's the audio driver, and in the 0.9.1a .. 0.9.2a sequence. What should be done now is really a git bisect, but since you are the only one which reproduce the error... Have you done such a thing?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-01-17

No, I didn't. No idea about git bisect.

Probably nobody else complained about this problem, because people prefer to use another type of hardware for receiving the IR signal to avoid dealing with these issues, and because the audio_alsa receiver isn't plug'n play, it requires some calibration to make it work, but once calibrated it works pretty well.

I'll try to see what's going on with the source code between 0.9.1a and 0.9.2a, but my skills are very limited to locate the piece of code with the bug.

Regards.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-17

hm... git bisect isn't that hard actually. Have you any git experience?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-25

Ping?

I have had shirt of time, but if possible I'm really interested in sorting this out. If you are interested, we could make a bisect session together, Basically, I would just ask you to rebuild and test some different git versions. This way we should be able to narrow down the window introducing this bug considerably.

However, I cannot debug this for myself, since I don't have the hardware.

THoughts?

Last edit: Alec Leamas 2016-01-25

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-01-25

Hi Alec, I'm available for any tests.

I was comparing the audio_alsa.c file in 0.9.2a Lirc with the old hw_audio_alsa.c in Lirc 0.9.1a, but they are almost identical and the minor changes between the two files don't seem to be the culprits of this bug. Might a library like receive.c is the culprit, since it introduced significant changes, but audio_alsa.c probably wasnt updated properly to work properly with the new Lirc engine. Or at least those are my thoughts.

Regards.

Last edit: danitool 2016-01-25

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-01-25

LIbrary or not, bisect is the brute force method which should reveal the truth, or at least narrow down the search.

The testing needed:

Install git if required.

Clone the repository:
$ git clone git://git.code.sf.net/p/lirc/git lirc
$ cd lirc

checkout next version and build it:
$ git checkout a31db88
$ ./autogen.sh
$ ./configure
$ make

You might run into problems with missing build dependencies. Look into html-source/install.html and try to solve whatever problems there are.

Read CONTRIBUTE.md, the "Running from Source tree" chapter.

Start lircd according to instructions in CONTRIBUTE.md. Then use irw as usual, but note it needs a specific socket to work.

Report back if it works or not.

BTW, could you send your email address to leamas dot alec at gmail dot com? We shouldn't spam the bug with all this; there's gonna be some writing...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-04-28

Ping? Unless I get some help from someone using this driver I will need to change the milestone to 0.9.5, probably late 2016...

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-04-29

status: open --> need-info

Milestone: 0.9.3 --> 0.9.4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-04-29

Hi Alec, sorry for abandoning the ticket. I'll try to make some tests with different revisions.

Regards.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-04-29

Well, I have abandoned the complete project for some time... Welcome back!

That said, if you plan to test different revisions, please use 'git bisect' - it's s imple tool which makes this process so much easier. The hard part is to be able to build and test, but you seem comfortable with that(?)

The short guide follows. Don't hesitate to ask for help!

Clone the release branch: git clone -b release-0_9_4 https://git.code.sf.net/p/lirc/git lirc

Check out the first known bad revision: git checkout lirc-0_9_2a

Build it: ./autogen.sh; ./configure; make;

Confirm that the bug indeed is present by testing

checkout the last known od revision: git checkout lirc-0_9_1a

Rebuild: make distclean; ./autogen.sh; ./configure; make;

Confirm that the bug indeed is gone by testing.

Now, all is set to use git bisect

$ git bisect start $ git bisect good lirc-0_9_1a $ git bisect bad lirc-0_9_2a

At this point, git bisect will checkout a new revision. Rebuild and test it. There are three possible cases:

1) The bug is present

$ git bisect bad

2) The bug is gone

$ git bisect good

3) The revision cannot be built or tested (yes, there are such ones... )

$ git bisect skip

In either case, git will checkout a new revision and eventually boil down to the very commit which causes this. Also, git bisect creates a useful log.

Last edit: Alec Leamas 2016-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-05-19

OK, no bisect going on (?) As a last try before releasing 0.9.4 I'm attaching a patch which basically reverts the audio_alsa driver to the 0.9.1a state besides what's necessary to actually compile it. The patch is against the release-0_9_4 branch. If someone could give this patch a try and report back we would at least know something.

EDIT: Updated patch.

EDIT: Also, please provide a complete log with --loglevel=trace. Why havn't we created such a one from the very beginning?

Last edit: Alec Leamas 2016-05-19

0001-plugins-Revert-audio_alsa-to-smallest-compiling-chan.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-05-20

Sorry for the delay. Building and testing revisions provided by git bisect is totally frustrating, most times I had to skip revisions due failures in builds. This is what I got

http://pastebin.com/AtTqNyAA

And these are some errors that forced me to make the skips:

http://pastebin.com/u8DJH6kp

I still didn't test your patch.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-05-20

yes, that part of the log should have been squashed, I know. There are many things to learn about git, for sure.

But basically the output says that this happens somewhere in 26 commits in the range

81a55d2 autotools: Don't allow configuring a single driver. .. f8e3053 autogen.sh: Updated.

It's somewhat confusing: the 81a55d2 commit is marked BAD whereas f8e3053 is marked GOOD. I assume that this is just is reversed and that the first commit actually works but the last doesn't, right? Still, 26 commits is far less than a few hundred.

EDIT: It's not confusing at all, my bad. It's just that f8e3053 i the last commit.

I will look into this, once I'm sober again ;) In the meantime, the missing piece is a log produced with -Dtrace2 from a version late enough to expose the error...

EDIT: preliminary conclusions:

The diff between old daemons/receive.c and new lib/receive.c is just that the new file has a int waitfordata(int timeout) implementation.

The diff between the old daemons/hw_audio_alsa.c and new plugins/autio_alsa.c is basically empty besides include files moved around.

So, the main difference seem to be that the old hw_audio_alsa used lircd's waitfordata() compared to the new using lib/receive.c:waitfordata(). The lircd waitfordata is a beast, an might very well do something required by audio_alsa.

Last edit: Alec Leamas 2016-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-05-21

Assuming this is indeed about waitfordata() I have prepared two patches. They are against "81a55d2 autotools: Don't allow configuring a single driver." Could you please try:

Reconfigure using --enable-debug --with-syslog

81a55d2 as-is, just to verify the bug is indeed present.

81a55d2 + 0001-plugins-audio*patch

81a55d2 + 0002-lib-receive-waitfordata*patch

File a log created using -D10 if bug is still there

and report back?

Last edit: Alec Leamas 2016-05-21

0001-plugins-audio_alsa-waitfordata-experiment.patch

0002-lib-receive-waitfordata-experiment.patch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-05-21

Ok, this is what I've made

git clone -b release-0_9_4 http://git.code.sf.net/p/lirc/git lirc3 git reset --hard 81a55d23049b7153207a943b3a7c890ca574c686 cd lirc3/ ./autogen.sh ./configure --enable-debug --with-syslog make

Tested to confirm the bug is present, indeed it is, key pressing returns previous key.

Now the first patch

make clean patch -p1 -i 0001-plugins-audio_alsa-waitfordata-experiment.patch make

Tested again, and the bug is gone!, every key pressing returns its own code.

And finally tested the second patch

make clean patch -R -p1 -i 0001-plugins-audio_alsa-waitfordata-experiment.patch patch -p1 -i 0002-lib-receive-waitfordata-experiment.patch make

With this patch the bug is also gone. So either using the first or else the second patch it solves the problem.

Thanks very much Alec.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-05-21

Actually, it's I who owe you a beer; thanks for hanging on in this complicated bug!

Unfortunately, while this is a great step forward, I still need your help to refine these patch(es). It's certainly not something we can commit to the main branch for various reasons. The most important is that I still don't understant why this works.

Attaching 2 patches based on 81a55d23. Could you make a try with both of them applied?

BTW: Since you have made a hard reset git checkout . might be the easiest way to reset the tree to a clean 81a55d23 state (patch -R becoming messy in the long run)

EDIT: These are git-formatted patches. You might want to use git am <patch file=""></patch> instead of patch to keep track of history.

EDIT: These two patches are based on 0001-plugins-audio_alsa-waitfordata-*patch i. e., you need to apply thbe patches 0001, 0003 and 0004 to test. Sorry fo the mess

Last edit: Alec Leamas 2016-05-21

0003-audio_alsa-remove-commented-tested-code.patch

0004-plugins-alsa_usb-Remove-release_event-client-reconne.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I've used the command
git checkout 81a55d23
not sure if this is the correct way to move to that revision

Then I've applied patches 0001, 0003 and 0004, rebuilt again and tested lircd with success, the bug isn't present.

this is what I get when I execute lirc, with the -n option

./lircd -n -U ../plugins/.libs/ --driver=audio_alsa -d plughw:2@24000 /etc/lirc/lircd.conf.d/RCT3004.conf 
Dumping parsed option values:
[lircd]=UNDEF
[lircd:nodaemon]=[True]                                                                                                                     
[lircd:driver]=[audio_alsa]                                                                                                                 
[lircd:device]=[plughw:2@24000]                                                                                                             
[lircd:output]=[/var/run/lirc/lircd]                                                                                                        
[lircd:pidfile]=[/var/run/lirc/lircd.pid]                                                                                                   
[lircd:plugindir]=[../plugins/.libs/]                                                                                                       
[lircd:permission]=[666]                                                                                                                    
[lircd:allow-simulate]=[No]                                                                                                                 
[lircd:repeat-max]=[600]                                                                                                                    
[lircmd]=UNDEF                                                                                                                              
[lircmd:uinput]=[False]                                                                                                                     
[lircmd:nodaemon]=[False]
[modprobe]=UNDEF
[lircd:listen]=UNDEF
[lircd:connect]=UNDEF
[lircd:logfile]=[/var/log/lircd]
[lircd:debug]=[False]
[lircd:release]=UNDEF
[lircd:allow_simulate]=[False]
[lircd:uinput]=[False]
[lircd:configfile]=[/etc/lirc/lircd.conf.d/RCT3004.conf]
lircd-0.9.2-devel[29918]: lircd(audio_alsa) ready, using /var/run/lirc/lircd
lircd-0.9.2-devel[29918]: accepted new client on /var/run/lirc/lircd
lircd-0.9.2-devel[29918]: accepted new client on /var/run/lirc/lircd

As you can see lircd got two clients, no idea if this is normal, since I only executed irw once. The first attached client is always there after a few seconds of executing lircd without executing any other lirc related stuff. Probably it's not important.

Alec Leamas - 2016-05-21

OK, this is either about better handling of the timeout, re-trying until the requested timeout has passed and/or that this variant re-initializes the hardware on failed attempts to get data.

've used the command
git checkout 81a55d23
not sure if this is the correct way to move to that revision

It sure is. You can check using git status -uno

As you can see lircd got two clients, no idea if this is normal, since
I only executed irw once.

Odd... Sure you don't have multiple irw processes runnnig? What says a simple

ps -ef | grep irw

Anyway, here are two new patches based on 81a55d23. If this works we have something we actually can apply to the current branches...

0005-plugins-audio_alsa-waitfordata-experiment.patch

0006-plugins-audio_alsa-Obsolete-select-poll.patch
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

danitool - 2016-05-21

Tested again with 0005 and 0006 patches applied, rebuilt and working quite fine, without the bug.

About the ghost attached client, I'm totally sure there isn't any process launched by me, or running when the notification is made. It also happens without these patches. BTW it doesn't seem to affect the correct behavior of lirc.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Alec Leamas - 2016-05-21

Great! It's a bit late here, but tomorrow I will finalize the patches for release and master branch. Hopefully,you will find some time, sooner or later, to test also those. But the should work....

For now: good night! Thanks for all your help.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

audio_alsa: LIRC returns previous remote key when pressing a new key

Linux Infrared Remote Control

Milestone

Searches

Help

#169 audio_alsa: LIRC returns previous remote key when pressing a new key

Related

Discussion