LSL4Unity on macOS - Cannot resolve open StreamOutlets.

[mattwehner]

With a clean Unity project and only the LSL4Unity package installed open StreamOutlets are not discoverable by .resolveStream or the resolver. The complex sample that passes the capsule to the cube using outlet/inlet is broken because the inlet never locates the open stream.

Is this a known issue? From reading earlier issues it looks like development has always been done on windows.

[cboulay]

Are you encountering this problem in the editor, in builds in MacOS, or in builds in iOS?

In my experience, I've had the resolver not work in the editor but it would work in a build. I'm guessing that the editor sandboxes the network somehow and doesn't allow multicast.

[gregbci]

@cboulay (I'm working with @mattwehner). We're both seeing the issue on macOS using a new Unity project with LSL4Unity.

The samples ComplexOutletInletEvent and SimpleInletScaleObject both fail because resolve_stream() doesn't find any streams.

Interestingly, the sample SimplePhysicsEventOutlet does work. It sends markers from Unity to a pylsl example without issue.

[gregbci]

I was able to make the ComplexOutletInletEvent work only once when built. So, this might be an editor thing, but there's also a cleanup problem (?)

[cboulay]

I'm glad you guys are working on this. Unfortunately, I don't have a magic bullet for you.

The main technical thing that the resolver needs that is different from an outlet is the ability to receive multicast packets. There are a bunch of relevant settings in the lsl_api.cfg. Can you try messing around with these? https://labstreaminglayer.readthedocs.io/info/lslapicfg.html#configuration-file-contents KnownPeers is especially useful.

[gregbci]

Thanks @cboulay for the tip. Sharing my recent findings:

I experimented with lsl_api.cfg: changing ports, resolve scope, setting KnownPeers to localhost, etc. Unfortunately, nothing seemed to help. ContinuousResolver.results is always empty when running in Unity.

Oddly, this works fine in Python on the same computer, same libraries, same lsl_api.cfg. Even the pylsl ContinousResolver works fine.

Using the SimpleInletScaleObject example, I can also see that Unity can send queries to Python, but Unity doesn't seem to be able to read the replies.

I added some logging to liblsl to compare Unity to Python. In the Unity case, I can see that resolve_attempt_udp::receive_next_result() doesn't seem to read anything from the socket. The handler passed to async_receive_from() never gets called for whatever reason.

So... I'm at a loss at this point. Maybe Unity does somehow "sandbox" multicast? I haven't managed to google anything of use. It seems odd to me that this "feature" would only exist on macOS.

[gregbci]

@cboulay Do you have a macOS machine to try this on if/when you have a moment?

I've tried this with Unity 2022.3 and 2021.3, neither works for me.

[cboulay]

I do have a Mac (ARM) but I recall having similar problems with the resolver. What is it you would like me to test? I don't have much time for the next couple weeks at least. Furthermore, you're better equiped than I am to find a solution, if one exists.

[gregbci]

Try the Complex Outlet Inlet Event sample. I've tried it on x86 and arm64 macs (play mode and builds). For me, the cube doesn't move.

[cboulay]

I understand. I agree it doesn't work. I don't know how to fix it so I don't know what I can do to help.

[gregbci]

Understood, and no worries - thanks for confirming. I'm not sure I can figure this one out either 😄

[SoloOne1]

Hi, did anyone manage to come up with a fix for resolving open streams for inlet?

[gregbci]

Hi, did anyone manage to come up with a fix for resolving open streams for inlet?

Not to my knowledge, I'm still seeing the problem on macOS.