pylsl not working on RaspberryPi

[dmedine]

Not sure how many LSL users out there on RaspberryPi, but I had a project recently and noticed a couple problems:

The distro that pip fetches on a pi does not come with a 32-bit build of liblsl. I also assume that the 64 bit builds that it does come with are not compiled for the ARM chip on a pi.

Also, after compiling the source(1.14.0), the library still doesn't work because of the name change. pylsl is still looking for liblsl32.so, not liblsl.so.

Looks like this was already handled (and I vaguely recall talking about it) in the module loading code in pylsl so I guess the only thing to do would be to roll a pi distro for pip. Again, probably not a high priority task, but I thought I would make a note of it before I forget.

I have some 32-bit liblsl.so's compiled for Raspberry Pi hot off the presses if anyone needs them.

[cboulay]

I have some 32-bit liblsl.so's compiled for Raspberry Pi hot off the presses if anyone needs them.

For the sake of finding it more easily in the future, you can manually attach those so's to the liblsl release page (after renaming them to something intuitive). This is what I do for the manylinux .so's for each pylsl release.

pylsl is still looking for liblsl32.so, not liblsl.so.

The latest release on pypi is 1.13.6. The lib finding code has been updated but I don't know if that made it into 1.13.6.

Side note: this reminded me of something else that needs fixing so I made an issue #37

roll a pi distro for pip

I don't know how to do that. Apparently manylinux2014 supports armv7l tags so it should be possible, but I expect there are dragons that way (e.g., Android vs Raspbian, armel vs armhf).

The correct solution is to not provide wheels for linux at all, so pip defaults to installing from source only, then the linux user has to separately install liblsl as a system-level package. @tstenner has done this before, but we shied away from making it an officially supported way of setting up liblsl because it's a different concept to how things work on Win/Mac which is where the majority of users are and it seemed like it wasn't worth the headache of supporting 2 different workflows for a very small number of users (most of whom can figure it out on their own eventually).

However, more and more users are wanting to use lsl on small devices with arm chips, so maybe installing liblsl at the system level should be the way in Linux.

In the interim, maybe we can make a custom wheel and upload it to piwheels somehow.

[dmedine]

There must be a way to do this. There are so many pip packages that are available for both pi and 'normal' linux computers, but I too have no idea how this works.

A custom wheel is a good stop-gap solution, though.

[dmedine]

I will upload my .so's to the release page. Something like 'liblsl-1.14.0-raspbian'? I can add it to the b4 release. It was built from today's (8.10.2020) source code.

[cboulay]

There must be a way to do this. There are so many pip packages that are available for both pi and 'normal' linux computers

According to piwheels.org, their cloud cluster scans pypi and automatically builds all the packages they find. This includes pylsl: https://www.piwheels.org/project/pylsl/

For pure Python projects, and projects where everything needed to build it can be found via setup.py, this just works. And Raspberry Pi OS has some configuration in it so its pip attempts to download from piwheels before pypi. That's actually why your pip install pylsl did anything at all, because if it tried from pypi it would have failed because there are no wheels with matching tags. Edit: I didn't expand the list. Now I see that piwheels hosts some old versions of pylsl (<=1.12) when they were 'source only', which in practice meant source + as many different lib files as we were packaging at the time but none for ARM. This is probably what you go.

Some options, as I see them:

• make liblsl an apt-installable package as mentioned above, AND provide better error messages when pylsl fails to load the lib so users know to install liblsl.
• make it so the piwheels build system builds liblsl or downloads it from the github release page. I opened an issue to ask about this: pylsl wheels on pypi come with binaries, how do I build and include them in piwheels? piwheels/packages#163

[tstenner]

make liblsl an apt-installable package as mentioned above, AND provide better error messages when pylsl fails to load the lib so users know to install liblsl.

I mostly agree. The liblsl distribution issues on non-Intel platforms start to affect the Unity users as well and I think it's easier to install it globally on these devices rather than figure out how to inform PyPI, nuget etc. about these platforms.

apt is a very comfortable distribution format that's trivial to build with CMake, for all others I'd just put the binary in an archive with a descriptive name and be done with it.

[xloem]

Bumped into this. Thoughts:

• finding another maintained package that does this and simply copying its approach could ease maintenance
• it would be good to have up-to-date instructions for getting this running on arm
• it's possible there wouldn't be armel vs armhf issues if there is little math code, but it can likely be fixed by specifying a compiler flag if there are

[PeterGamma]

If nothing works: buy a LattePanda V 1 instead of a Raspberry Pi .

[scmisa]

Hi, I'm attempting to compile liblsl for RaspberryPi Zero W, which is on ARM architecture, and instructions are unclear for me, and i need some pointers and How to do this

[cboulay]

You need to install liblsl to your system. See if the ARM build here works for you: https://github.com/sccn/liblsl/releases
If not then you'll have to build liblsl on your target machine.

After it's installed, you can just pip install pylsl and it should work.

[PeterGamma]

Would be nice if someone could show that Flavio Frohlich was wrong and gets LabStreamingLayer to run on a Raspberry Pi. But has this not something to do with old code which is included in LabStreamingLayer which does not run on ARM? Matlab for instance does not run on ARM based SBCs either as far as I know, but only Octave.

[xloem]

LSL requires the user to perform manual installation on the pi but should indeed run, see #36 (comment) #36 (comment) alexandrebarachant/muse-lsl#140 (comment) https://github.com/JohnGriffiths/eegnb_rpi/blob/main/installation_notes.md alexandrebarachant/muse-lsl#140 (comment) alexandrebarachant/muse-lsl#140 (comment)
It sounds like there may be an issue specifically connecting to the Muse on newer Pis (which is quite sad as it may require a developer with reverse engineering experience and access to both hardware items to fix).

[PeterGamma]

Before starting reverse engineering, I would rather use OpenBCI with BrainFlow. There is an example for the Raspberry Pi. And eventually you are lucky and get a Chinese OpenBCI Cyton clone to work. Can save you some money.

[PeterGamma]

The most direct way would be to use PiEEG for the Pi, which is a Raspberry Pi EEG shield. But I heard some rumors that there are issues with PiEEG and noise. PiEEG recommends to connect the Pi digital Ground pin to the client. I would also rather do some noise reduction experiments with PiEEG before starting reverse engineering. And if Interaxon does not want to support that we access Muse data, the question arises, if it is not better to choose another platform which supports that we access the EEG data.