RaySession exported from Distrobox (Podman wrapper) container not consistently spawning and connecting to ray-daemon

[Messaiga]

Hi!

I'm trying to use RaySession inside an Arch Linux container running with Distrobox and Podman, and every time I run RaySession it fails to connect to ray-daemon.

If I run ray-daemon -p 16187 and then run RaySession, it connects reliably every single time.

I'm feeling this is an issue caused by running it in a container that lacks an init system like systemd, but if there's any consistent work around to this where I can still run the program without having to open a separate terminal to run ray-daemon then I'll take the easy way out.

[Houston4444]

I am not sure to understand everything. What I understand is:

• if you run RaySession directly from desktop shortcut or from the raysession terminal command, it fails to connect to the daemon and it shows this Daemon URL dialog
• if you run first ray-daemon -p 16187 and then start RaySession, all works fine.

Is it correct ?

If it is correct, could you check if the ray-daemon process is running when you start normally raysession ? I have no idea what happens for the moment, but it is good to know if the daemon failed to start or if it is an OSC communication issue.

It would be interesting to know what happens if you start the daemon with: ray_control start.

I advise to use the ray-daemon command only if you run it for network sessions (almost no one use them), because by default, ray-deamon command will starts with the default network session directory as sessions root directory (by default: ~/Ray Network Sessions instead of ~/Ray Sessions.

[Messaiga]

I am not sure to understand everything. What I understand is:

if you run RaySession directly from desktop shortcut or from the raysession terminal command, it fails to connect to the daemon and it shows this Daemon URL dialog
if you run first ray-daemon -p 16187 and then start RaySession, all works fine.

Is it correct ?

You're correct.

After running RaySession from the desktop shortcut, I ran this in terminal and have this output.

ps -ef | grep ray-daemon
ryan      217456  206471  0 14:53 pts/0    00:00:00 grep ray-daemon

It seems ray-daemon doesn't start at all when RaySession is ran this way.

When running raysession from the terminal, I get:

❯ raysession 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
usage: ray-daemon [-h] [--session-root SESSION_ROOT] [--session SESSION] [--osc-port OSC_PORT] [--findfreeport] [--no-options] [--hidden]
                  [--config-dir CONFIG_DIR] [--debug] [--debug-only] [--no-client-messages] [-v]
ray-daemon: error: argument --gui-url: 'osc.udp://pyrite-studio.ryan-wyrestorm:12823/' is an unknown osc url

When ray_control startis ran, I get:

pyrite-studio% ray_control start
daemon terminates, sorry

[Houston4444]

So, the incriminated code part is here: https://github.com/Houston4444/RaySession/blob/5027a90e124252c533db8978859a753d4b8b0e06/src/shared/ray.py#L343 .

It seems that your system does not support direct OSC sends from liblo, I don't know why. I suppose that oscsend command line interface will not work too (in debian it is in liblo-tools package).

In RaySession, it is the only case where liblo.send() is called, and TBH I don't remember why this check is done (not enough comments from myself maybe ... ;)). I just made another branch without this check here : https://github.com/Houston4444/RaySession/tree/no_ping_check could you try to use it ? (I have to investigate why I did estimate it was needed before to remove this check from the master branch).

[Messaiga]

Got around to this today finally!

The GUI seems to behave the same as before. Here's the run and the results.

[messaiga@pyrite-studio RaySession]$ ./src/bin/raysession
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Traceback (most recent call last):
  File "/home/messaiga/raysession-test/RaySession/src/bin/ray-daemon", line 103, in <module>
    server.announce_gui(CommandLineArgs.gui_url.url,
  File "/home/messaiga/raysession-test/RaySession/src/daemon/osc_server_thread.py", line 1438, in announce_gui
    self.send(gui_addr, "/ray/gui/server/announce", ray.VERSION,
  File "/home/messaiga/raysession-test/RaySession/src/daemon/osc_server_thread.py", line 1410, in send
    ClientCommunicating.send(self, *args)
  File "src/liblo.pyx", line 538, in liblo._ServerBase.send
  File "src/liblo.pyx", line 160, in liblo._send
OSError: sending failed: b'Name or service not known'

I ran this directly from the cloned repo - should I build it and see if I find any difference?

[Houston4444]

Mmmh, so I don't know, sorry. The most surprising is that it can works when ray-daemon is launched before. I'll try it myself if I found some time for that. Thanks for the test.

I ran this directly from the cloned repo - should I build it and see if I find any difference?

I really don't think that it could change anything.

[Houston4444]

Maybe, it's something related to network security that prevents liblo to find the address osc.udp://pyrite-studio.ryan-wyrestorm:12823/ , which is the GUI OSC address.

In this case, the GUI starts the daemon with a --gui-url argument and the GUI OSC address. Something I could do is to change this behavior with a --gui-port argument (if the GUI starts the daemon, then they both are on the same machine). Even with that, I think that Network sessions will be broken for you, but near no one use them.

[Messaiga]

For some context on my use-case - I'm attempting to create an OCI for usage with Distrobox and Podman that includes RaySession, and I'm not attempting to use RaySession over the network between machines. So if RaySession can properly launch ray-daemon then connect to it within the same container, it'll be perfect!

If you want to build and test a similar environment, here's more details.

Host System - Bluefin (a customized image of Fedora Silverblue). Container Runtime - Podman Container Runtime Wrapper - Distrobox Container Image - pyrite-studio. I haven't created documentation yet but I can make some quick docs for usage.

I'm going to test other bases for an OCI to run RaySession and other programs - trying to see if the same thing happens in a Debian, Ubuntu or Fedora environment maybe. If I find out anything new I'll update here :)

[Houston4444]

I just updated the 'no_ping_check' branch, with the gui starting the daemon with --gui-port argument. By chance, this argument was already existing in the daemon (I did not remember ;)).

[Messaiga]

I just cloned it and attempted to run, here's the logs!

pyrite-studio% pwd
/home/ryan/raysession-test/RaySession/src/bin
pyrite-studio% ./raysession
Traceback (most recent call last):
  File "/home/ryan/raysession-test/RaySession/src/bin/./raysession", line 15, in <module>
    from gui_session import SignaledSession
  File "/home/ryan/raysession-test/RaySession/src/gui/gui_session.py", line 6, in <module>
    from client_properties_dialog import NsmClientPropertiesDialog
  File "/home/ryan/raysession-test/RaySession/src/gui/client_properties_dialog.py", line 12, in <module>
    from child_dialogs import ChildDialog
  File "/home/ryan/raysession-test/RaySession/src/gui/child_dialogs.py", line 22, in <module>
    import ui.new_session
ModuleNotFoundError: No module named 'ui'
pyrite-studio% 

[Houston4444]

you need to make !!!

[Messaiga]

Ah I'm a fool! We've got something promising now :)

pyrite-studio% ./src/bin/raysession 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[ray-daemon]GUI connected at osc.udp://localhost:13593/
[ray-daemon]URL : osc.udp://192.168.1.5:16187/
[ray-daemon]      osc.udp://pyrite-studio.ryan-wyrestorm:16187/
[ray-daemon]ROOT: /home/ryan/Ray Sessions

I'm noticing that RaySession can open some applications within the session but not others. Here's what happens after opening a session where it attempts to load Jack Connections.

[ray-daemon]Attempting to open /home/ryan/Ray Sessions/test
[ray-daemon]Commanding smart clients to switch

[JACK Patch Memory-patch]
Traceback (most recent call last):
  File "/home/ryan/raysession-test/RaySession/src/bin/ray-jackpatch", line 6, in <module>
    main_loop.run()
  File "/home/ryan/raysession-test/RaySession/src/clients/jackpatch/main_loop.py", line 478, in run
    nsm_server.announce(
  File "/home/ryan/raysession-test/RaySession/src/clients/jackpatch/nsm_client.py", line 119, in announce
    self._send_to_daemon(
  File "/home/ryan/raysession-test/RaySession/src/clients/jackpatch/nsm_client.py", line 113, in _send_to_daemon
    self.send(self._daemon_address, *args)
  File "src/liblo.pyx", line 538, in liblo._ServerBase.send
  File "src/liblo.pyx", line 160, in liblo._send
OSError: sending failed: b'Name or service not known'

[ray-daemon]Telling all clients that session is loaded...
[ray-daemon]Loaded
[ray-daemon]Done

I'll test further and see what I find. Thank you so much!

[Houston4444]

Oww, you edited the message, then I have not seen any notification for that. Is ray-jackpatch the only program with this problem ?

[Messaiga]

Other programs throw different issues.

On launching Carla:

[carla-jack-multi-Carla]
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

(process:195711): Gtk-WARNING **: 10:46:03.256: Locale not supported by C library.
    Using the fallback 'C' locale.
Carla 2.5.7 started, status:
  Python version: 3.11.6
  Qt version:     5.15.11
  PyQt version:   5.15.10
  Binary dir:     /usr/lib/carla
  Resources dir:  /usr/share/carla/resources

Here's Carla ran outside of Raysession but within the pyrite-studio container. It works without issues this way.

[ryan@pyrite-studio ~]$ carla
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

(process:201366): Gtk-WARNING **: 10:52:53.365: Locale not supported by C library.
    Using the fallback 'C' locale.
Carla 2.5.7 started, status:
  Python version: 3.11.6
  Qt version:     5.15.11
  PyQt version:   5.15.10
  Binary dir:     /usr/lib/carla
  Resources dir:  /usr/share/carla/resources
Frontend pixel ratio is 1.0
libjack.so.0 loaded successfully!
[carla] Carla assertion failure: "newFrames > 0" in file CarlaEngineInternal.cpp, line 260

On the other hand, a program like ZynAddSubFX V3.0.6 works without any issues.

[zynaddsubfx-zynaddsub]

ZynAddSubFX - Copyright (c) 2002-2013 Nasca Octavian Paul and others
                Copyright (c) 2009-2019 Mark McCurry [active maintainer]
This program is free software (GNU GPL v2 or later) and 
it comes with ABSOLUTELY NO WARRANTY.

Try 'zynaddsubfx --help' for command-line options.

Sample Rate =       48000
Sound Buffer Size =     256 samples
Internal latency =  5.3 ms
ADsynth Oscil.Size =    1024 samples
lo server running on 19925
[INFO] Nio::start()
Starting Audio: JACK
Jack buffer resized
Audio Started
Starting MIDI: JACK
MIDI Started
Warning: Can not lock memory: Cannot allocate memory
Time for a fast load is 1.357ms load(0.008) class(0.0) spawn(1.349)...
making reverse graph[1103]<0.728 ms>

[Houston4444]

Thinking to this, it seems that (at least with liblo), you can't recognize your localhost from an URL. And NSM can't work at all normally, because a program under NSM is started with NSM_URL=osc.udp://domainname:PORT_NUM/.

So, are you sure that any program can run correctly ? I mean, it's client state should become 'ready' and not 'launched', and save the client should be effectively applied.

[Messaiga]

It may only run partially correct - I can confirm that the client state becomes 'launch' when I open ZynAddSubFX rather than 'ready'.

Despite this I can route it in the patchbay and it outputs audio to the node it's routed to.

[Messaiga]

Do you think I could find some useful information by reading through the New Session Manager API specs?

[Houston4444]

Do you think I could find some useful information by reading through the New Session Manager API specs?

I think no.

Could you report here the contents of the file /etc/hosts ?

[Houston4444]

I see that I also have a file /etc/hostname containing only my host name.

[Messaiga]

Alright, I'll not spend that time then. Here's the output for each:

cat /etc/hosts
# Loopback entries; do not change.
# For historical reasons, localhost precedes localhost.localdomain:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# See hosts(5) for proper format and other examples:
# 192.168.1.10 foo.mydomain.org foo
# 192.168.1.13 bar.mydomain.org bar

[ryan@pyrite-studio ~]$ cat /etc/hostname
pyrite-studio.ryan-wyrestorm

[Houston4444]

I'll suggest to modify /etc/hosts this way and try (maybe restart the computer).

# Loopback entries; do not change.
# For historical reasons, localhost precedes localhost.localdomain:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.1.1   pyrite-studio.ryan-wyrestorm
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
# See hosts(5) for proper format and other examples:
# 192.168.1.10 foo.mydomain.org foo
# 192.168.1.13 bar.mydomain.org bar

[Messaiga]

I edited it and it seems to work without any further tweaks! I'll make a proper test setup for this and try to do actual music production in it to see how it behaves.

This now works with the RaySession package built through AUR so the fork won't be necessary.

If this is the solution then it looks like I'll be including it in the documentation for my project until I can find a better solution. Maybe I can change the hostname in the container when it's assembled.

Regardless, I think we can consider this closed! You're greatly appreciated.

[Houston4444]

Nice, I am happy for you !