#218 Lirc audio_alsa stopped working kernel 4.5.5 fc24

[Keith Bennett]

Updated my mythbox from fc20 to fc24 and Lirc no longer works with the audio_alsa driver.
Mode2 produces no output. Audio is working fine still and the hardware hasn't changed. Tried running as root, selinux and firewall disabled, no difference. Irrecord gets to the 'checking for ambient light' stage and hangs. Even tried the hardware on my netbook running a clean install of fc24 and same result. I've run out of ideas so any help appreciated!
Many Thanks.

[Alec Leamas]

Hm... Obviously, this is related to a kernel change. You are using the samei lirc version, right? It might make sense to discuss this on a kernel list. Any change like this is by definition a kernel bug - the idea is that the kernel user-space interface is stable.

The alternative would be to try to debug the audio_alsa driver. Is there any hint in the logs if raising the debug level to at least 'debug'?

EDIT: Unless you can find something in the lirc logs, the only option which really pushes things forward is to make a kernel bisect to find the chenge which caused this. However, given the large span this will needs some cycles, for suer.

[Keith Bennett]

Thanks for your quick reply Alec. The Lirc version would have been 0.9.0 before, should have updated sooner really.
Nothing usefull in the Lirc logs even at level 10, everything appears to start but no data.
Either the driver isn't getting any audio from alsa or lirc isn't getting any from the driver or maybe it's just hanging. Any suggestions on how to diagnose welcome!

[mediapc@mediapc ~]$ mode2 --driver=audio_alsa --device=hw@48000,r
Using driver audio_alsa on device hw@48000,r
Trying device: hw@48000,r
Using device: hw@48000,r

And in the log-

[mediapc@mediapc ~]$ cat .cache/mode2.log
Aug 13 21:11:22.713018 mediapc.37 mode2: Debug: mode2:  Opening log, level: Debug
Aug 13 21:11:22.713171 mediapc.37 mode2: Info: Opening device: hw@48000,r
Aug 13 21:11:22.713208 mediapc.37 mode2: Info: Initial device: hw@48000,r

Just tried xmode2 and that may give some clues-

[mediapc@mediapc ~]$ xmode2 --driver=audio_alsa --device=hw@48000,r 
Using driver audio_alsa on device hw@48000,r
Cannot initialize hardware

In the log file-

[mediapc@mediapc ~]$ cat .cache/xmode2.log
Aug 13 21:11:56.506469 mediapc.37 xmode2: Debug: xmode2:  Opening log, level: Debug
Aug 13 21:11:56.506651 mediapc.37 xmode2: Info: Initial device: hw@48000,r
Aug 13 21:11:56.506699 mediapc.37 xmode2: Warning: Cannot access device: hw@48000,r
Aug 13 21:11:56.506751 mediapc.37 xmode2: Notice: Cannot open /sys/class/rc

Aug 13 21:11:56.506798 mediapc.37 xmode2: Notice: Cannot open /sys/class/rc

Aug 13 21:11:56.506829 mediapc.37 xmode2: Info: Cannot configure the rc device for hw@48000,r
Aug 13 21:11:56.506862 mediapc.37 xmode2: Error: could not get file information for hw@48000,r
Aug 13 21:11:56.506897 mediapc.37 xmode2: Error: default_init(): No such file or directory

Not sure if that is relevant though.

Thanks, Keith

[Alec Leamas]

Here are actually a lot of questions... One major problem is that lirc has undergone very large changes between 0.9.0 and 0.9.4; but also the kernel might be the culprit.

The xmode logs are really not useful. However, mode2 clearly demonstrates the problem. Are you sure the alsa device is OK? Is there any way do demonstrate that there is something? aplay?

Out of the top of my head, the only idea I can find would be to try fc22 and also fc21 or fc23 depending on the outcome of f22 to first establish at which fedora release this happened. That would be a starter. Perhaps you could just spin up the live CDs, install lirc and make a quick test with mode2 for each version?

Also note [#169]. Although the same driver, it's probably not the same bug. Still, here are some hints how we worked to fix that one. Also, it shows that the driver sort of works for some users in 0.9.4.

[Keith Bennett]

Hi Alec,
I tried installing 0.9.0 from source to see what happens. Initially it didn't work until I tried irrecord which started producung output. Then I found that mode2, and then lircd, would work when logged in as root but not through sudo.
So at least I've found something that works now, but it looks like there is something going on with permissions as well as something in the newer lirc versions. I'll do some more experimenting when I get a chance.

Regards,

Keith

[Keith Bennett]

Although my remote now works there's nothing on TV apart from Olympics so I did a bit more compiling and testing. With 0.9.1a mode2 works and produces output, but I couldn't get anything with 0.9.2a.
So perhaps there is some commonality with the other bug.
Let me know if I can help by checking anything else.

Regards,

Keith

[Alec Leamas]

Hm... this is great progress. Given [#169], could you test the commits 81a55d2 and f8e3053?

Here, I'm assuming you are used to git. Let me know otherwise.

If you havn't found it, there are instructions in CONTRIBUTE.md how to run things after a build without installing them. This is for lircd; running mode2 is similar but much simpler

[Keith Bennett]

I had a go at that following the instructions in contribute.md and the other thread, and after installing the first one I got-

[Keith@localhost tools]$ ./mode2  --driver=audio-alsa --device=hw@48000,r --plugindir=../plugins/.libs
Driver `audio-alsa' not supported.

Not sure if that is meaningful or just something I've messed up in the compilation though!

[Alec Leamas]

The correct name seems to be audio_alsa, not audio-alsa ;) E. g., 'irrecord --driver foo' lists the available drivers.

[Keith Bennett]

Doh - it still doesn't work though and gives the same response. Not sure how mode2 decides where to look for its plugins, but it doesn't seem to find any at the moment.

[Alec Leamas]

It's kind of complicated. The commit [f8e305] is before the plugin system was introduced. In this version, you need to run ./configure with the proper options; perhaps you could just use --with-driver=audio_alsa or --with-driver=userspace. You probaly want to use --debug as well. But in runtime, just --driver and --device should work.

In next commit [81a55d] the plugin system is in place and you will need LIRC_PLUGINDIR=../plugins.libs when running mode2. Looks like the --pliugindir stuff isn't in place for mode2 at this point. OTOH, ./configure can be run with just --debug.

[Keith Bennett]

Afraid I'm struggling a bit with this Alec, can't get round the plugins problem in 81a55d2 so thought I'd try f8e3053 today.

git clone git://git.code.sf.net/p/lirc/git lirc
cd lirc
git checkout f8e3053
./autogen.sh

gives-

automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
./autogen.sh: line 9: cd: plugins: No such file or directory
./autogen.sh: line 9: ./make-pluginlist.sh: No such file or directory

The plugins directory doesn't appear at all now, probably down to my unfamiliarity with git.

[Alec Leamas]

As I said, in [f8e305] there is no plugins directory because this is before the plugin system was introduced. That said, these parts of the history is a mess full of problems. I am able to build f8e305 using

git clone git://git.code.sf.net/p/lirc/git lirc-hugo
git clone git://git.code.sf.net/p/lirc/git lirc-hugo
git checkout f8e3053
git checkout master plugins/make-pluginlist.sh
git checkout master plugins/Makefile.am
./autogen.sh # possibly run it twice.
./configure --with-driver=userspace
make
cd tools
./mode2 --driver default --device /dev/lirc0 
# I cannot test the audio_alsa driver...

As for next commit, I can build it using:

git stash
git stash drop
git checkout 81a55d
./autogen.sh
./configure
make
cd tools
LIRC_PLUGINDIR=../plugins/.libs ./mode2 --driver default --device /dev/lirc0
# again, I cannot use the audio_alsa driver

[Alec Leamas]

There are a few more tricks here (I have actually worked with this mess some time ago). To reset, you might need to do

make distclean
./autogen.sh

Also, permissions is a much bigger problem at this point in the history. Yóu might have to run mode2 as root to walk-around these issues for now.

[Keith Bennett]

Great, thanks. I managed to get both of those to work and get mode2 to produce output and even got lircd to decode it.
Hope that helps to track it down. If you don't have the hardware to test audio_alsa I could send you a wav file with some rc chirps&burps recorded. This works if played through a loopback (modprobe snd_aloop)

[Alec Leamas]

Well, well, well. This is also great progress. We now know that the offending commit is somewhere in between [81a55d] and lirc-0_9_2a.

If you still have an interest in tracking this down, what needs to be done is a 'git bisect'. This way we will be able to find the offending commit. You will find multiple howtos on this, but in short we do:

git bisect start
git bisect bad lirc-0_9_2a.
git bisect good 81a55d

At this point git will checkout a version more or less in the middle of these two commits. You need to build, and run mode2 again. There are three possible results The first is that mode2 works, and we do

git bisect good

The other possibility is that doesn't work and we do

 git bisect bad

In case we can't build or test we do

git bisect skip

In any of these cases git will checkout a new version to build and test. After a few rounds git will have a single commit left and tell you this . At that point, I should be able to make a patch... (knock. knock...)

[Keith Bennett]

Here you go-

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
9f0227d82a67aa36b0112d21d691899a836393ed
82305c72c497c2884a7cdbfd1f9205049713c6eb
We cannot bisect more!

I skipped few because I got

configure.ac:23: installing './config.sub'
configure.ac:9: installing './install-sh'
configure.ac:9: installing './missing'
daemons/Makefile.am: installing './depcomp'
automake: error: cannot open < plugins/pluginlist.am: No such file or directory
autoreconf: automake failed with exit status: 1

[Alec Leamas]

The skipped one is not a problem. Seems that the problematic change is this

-

+                       short stmp;
                    if (bytes_per_sample == 2) {
-                               cs = ((*(short *)
-                                      &buff[i * bytes_per_sample * alsa_hw.num_channels +
-                                            bytes_per_sample * alsa_hw.channel]) >> 8);
+                               stmp = buff[i * bytes_per_sample * alsa_hw.num_channels +
+                                            bytes_per_sample * alsa_hw.channel];
+                               cs = stmp >> 8;
                                cs ^= 0x80;

I'm busy now, but feel free to try rectify this if you want. Otherwise I will come up with a patch, late tomorrow or Thursday.

[Keith Bennett]

Interesting, so the bug is to do with not being to able to cope with 16 bit audio and nothing to do with the OS. Presumably it would work with 8 but I don't think I have a way to test that.
The way that it truncates down to 8 has been changed but I can't what that achieved so probably best if you can fix it!

[Alec Leamas]

I should be doing something else, but cannot get this out of my head. Attaching a patch againt lirc-0_9_2a. Could you give it a try and report back?

[Keith Bennett]

OK, it took me while because version 0.9.2a was fighting back a bit. mode2 kept giving me segmentation faults or couldn't find its plugins which is frustrating because I know I had it working previously. Turns out that if you give it either LIRC_PLUGINDIR or -U it screws up, but if you leave them both out it defaults to the right place.

Anyway, I can confirm that your patch is a fix!

I know the feeling that I should be doing something else!

[Alec Leamas]

OK. I have bulit new 0.9.4b packages with this patch included [1]. Could you try to update to these to check that it stlll works (knock, knock again)

[1] https://leamas.fedorapeople.org/lirc/lirc-0.9.4b/

[Keith Bennett]

The machine I've been testing with is running fc24 i686 but I have fc23 x86_64 on another.
I can confirm that mode2 with audio alsa works on that with your new packages.
If you can produce the fc24 i686 version I'll check it.
Cheers.

[Alec Leamas]

Hey, I'm a packager. And those are supposed to be able to produce rpms :) i386 is on https://leamas.fedorapeople.org/lirc/tmp-i386/

[Keith Bennett]

Top job Alec, thanks for sorting this so quickly. It's good to know that bugs can get fixed even when the user base is obviously not massive ;)