libLSL for WASM

[neurobe]

Hi. Looking to open a dialog - Has libLSL on WASM been discussed?

Having done a little research to see whether we could bring LSL into our web technologies project ( www.biosignal.network ), to my untrained eye, the answer is yes. The big question might have been as to whether the emscripten transpiler supports threading and it seems that for the past year or so it does (including boost.threads), and Chrome and FF support (on desktop) the pre-requisite shared memory buffer standard.

I am aware that there are one or two node implementations, however IMO a pure browser approach gives a clean solution compared to, say, the Electron route. (We looked into Electron but have rejected it)

I would see our own evolution as starting with the LSL Push Interface, evolving to Push & Pull.

Appreciate any thoughts on this.

[cboulay]

That's interesting. A friend and colleague recently developed a browser extension for BCI2000 so I know the field would fine utility in this kind of project in LSL too. But, this is the first I've heard of it, so maybe it simply hasn't occurred to anyone before.

[tstenner]

Anything that runs in a browser sandbox will not be able to open the sockets for network communication, so unless you have a gateway / new protocol version that uses websockets it's going to be difficult. (For the record: I think it's a good thing a browser doesn't have this kind of access to the local network.)

[neurobe]

Well emscripten provides at least some support for Boost.ASIO. Apparently it puts a sockets wrapper on webSockets to interface to the C code. But yes, it must then expose it to the Browser as a webSocket and the browser would then enforce same-origin policy.

For my application, and for many I would think, at least for implementing the LSL push interface, CORS (cross origin permissions (to the local network? - I guess so) to just one origin, would do the trick nicely.

I think tho, that might involve a significant change to libLSL.

Looks like I will be forced to a less elegant Electron solution to provide a separate, standalone LSL interface (that is an entirely separate app, wrapping our web App) whilst our App proper runs exquisitely in the browser - the browser in large measure performs the same function as Electron and Cmake build systems (ie cross-platform capability) but much more elegantly (without drivers, and with instant updates).
C'est la vie.

[tstenner]

Even then you'd have to discover the stream.

The current process is:

• the outlet subscribes to multicast packets
• before creating an inlet, a discovery packet is sent via broadcast/multicast
• the outlets checks if the query matches the stream and replies with the connection parameters (IP, ports)
• the inlet connects

So, even if you could open a plain TCP socket and get your outlets to connect to the stream, you'd still need the time offsets (which are currently synchronized via UDP), otherwise you'd just stream data without any useful time information.

The protocol for data exchange is simple and should be quite easy the replicate in javascript / typescript. The time exchange could work over TCP, but it's modeled after PTP (IEEE 1588), and a TCP exchange would need a different clock exchange and delay calculation. The outlets still wouldn't be discoverable, but scanning all IP addresses in the config file could work.

If someone were to volunteer I could mentor them, but I neither have the time nor the websockets experience to do this.

[neurobe]

Nice explanation - I begin to see the difficulties.
From the few tests I have done, the LSL discovery system works beautifully - that is why I was keen to participate (as well as a few customer requests!)
Early tests on the Electron package approach are positive. Might have the Inlet implemented in a day or two using Urish/Node-LSL module.

[dioptre]

I'm interested in this also, WASI might be useful too...