search

SoundScapeRenderer / ssr

Main source code repository for the SoundScape Renderer
http://spatialaudio.net/ssr/
GNU General Public License v3.0
134 stars 53 forks source link

CI: build SSR on Windows #352

Open mgeier opened 1 year ago

mgeier commented 1 year ago

For now this is just an experiment to check whether it's possible to compile the SSR with MSYS2.

This is already building .exe files (see e.g. artifacts at https://github.com/SoundScapeRenderer/ssr/actions/runs/5191333285), but I don't expect them to actually work. I guess some dependencies will be missing.

For this to be usable, the following steps would have to be completed:

There are more things to do, but I think those can be done at a later point (in separate PRs), once we know that everything else works:

Several of those things are already done in #351.

HaHeho commented 1 year ago

This is already building .exe files (see e.g. artifacts at https://github.com/SoundScapeRenderer/ssr/actions/runs/5191333285), but I don't expect them to actually work. I guess some dependencies will be missing.

I briefly tried some of these executables after starting JACK. Either by running from the file explorer or via PowerShell, I didn't get any reaction what so ever.

chris-hld commented 1 year ago

It might be an issue with QT, it was super hard to get running on windows, as it doesn't complain but just wouldn't start. There are quite a few required extra flags and packages, such as the platform support libs. Could you try to compile without GUI, would that at least give a reaction?

mgeier commented 1 year ago

Thanks for testing!

I expected something to be wrong, because the files are too small.

And thanks for the suggestion to disable the GUI, here are the artifacts without GUI: https://github.com/SoundScapeRenderer/ssr/actions/runs/5204312742?pr=352

mgeier commented 1 year ago

I might have to use -mwin32 ... at least then the .exe files have a "reasonable" size: https://github.com/SoundScapeRenderer/ssr/actions/runs/5210031866?pr=352

Now each .exe file has a size of 44MB. Now maybe they actually work?

Maybe we can get them smaller, as @chris-hld mentioned in https://github.com/SoundScapeRenderer/ssr/pull/351#issuecomment-1580124891?

HaHeho commented 1 year ago

I might have to use -mwin32 ... at least then the .exe files have a "reasonable" size: https://github.com/SoundScapeRenderer/ssr/actions/runs/5210031866?pr=352

Now each .exe file has a size of 44MB. Now maybe they actually work?

Quickly tried, executed via double click from file explorer, getting the following three errors.

Error1 Error2 Error3

mgeier commented 1 year ago

Thanks for testing!

Those error messages look reasonable. I guess those DLLs exist on the build server, but the CI is only uploading the EXE files.

I would hope that the NSIS installer will take care of copying those DLL somehow ... @chris-hld is this true? If not, we'll have to manually move a few files around.

I have worked a bit more on this and I have implemented a --enable-windows-installer option. It doesn't yet actually create an installer, but there is a Makefile variable WINDOWS_INSTALLER which contains the desired name of the installer, and the files for the installer are generated in the directory windows-installer when running make nsis. Within this directory, there is a sub-directory PkgData which contains the data that the SSR needs (GUI images etc.). Currently, SSR_DATA_DIR is set to PkgData but maybe this has to be changed?

All directory names can of course be changed if necessary.

NSIS should already be installed on the MSYS2 system.

@chris-hld Would you like to try adding your installer setup from #351?

chris-hld commented 1 year ago

I would hope that the NSIS installer will take care of copying those DLL somehow ... @chris-hld is this true? If not, we'll have to manually move a few files around.

No, I don't think that's possible. NSIS is really just a way of compressing specified binaries to a single installer, plus maybe some extra checks etc. I used an MXE tool to collect and copy the correct cross-compiled dependencies with ../mxe/tools/copydlldeps.sh --indir ./ssr-win-bin --destdir ./ssr-win-bin/deps --recursivesrcdir ../mxe/usr/x86_64-w64-mingw32.shared/ --srcdir ./_build --copy --enforcedir ./_build/*.dll --enforcedir ../mxe/usr/x86_64-w64-mingw32.shared/qt5/plugins/platforms/

There seems to be an alternative for MSYS2 https://github.com/msys2/MINGW-packages/issues/5204 What worries me a bit is that it is mentioned that MSYS2 is not intended to be portable, so compiling on CI is pointless?

mgeier commented 1 year ago

What worries me a bit is that it is mentioned that MSYS2 is not intended to be portable, so compiling on CI is pointless?

I'm not sure if that's true.

I don't really know any of this, but I do know that we are using MSYS2 to compile our Pd externals and they seem to work fine, and they don't have any strange MSYS2 dependencies.

Their dependencies are collected here:https://github.com/SoundScapeRenderer/ssr/blob/4d9981daf8cf26a97b69885fd160035837cf61fe/.github/workflows/pd-externals.yml#L127 ... which uses this: https://git.iem.at/pd/iem-ci/-/blob/main/localdeps/localdeps.win.sh ... which in turn uses ntldd

I don't understand the comment that suggests using MINGW64 (https://github.com/msys2/MINGW-packages/issues/5204#issuecomment-483128612), because this somehow seems to be already used within MSYS2.

Although nowadays using UCRT64 seems to be preferred: https://github.com/msys2/setup-msys2#msystem (that's why I'm using it here, but I can switch to MINGW64, if that turns out to work better).

I'll try if I can get the necessary files from ldd as suggested here: https://github.com/msys2/MINGW-packages/issues/5204#issuecomment-1013818547

chris-hld commented 1 year ago

Ok, that might be worth a try! I just plugged in the msys2 compiled exe into the folder containing all the cross-compiled dependencies I collected using MXE and it seems it only complained about missing libfmt for me. So there might be some msys2 specifics, but maybe it's not a lot.

mgeier commented 1 year ago

In 637f99e0b936ac3b528c229cae6f8ca602976db0, I have used ldd to find the DLL dependencies, and they are now included in the artifact: https://github.com/SoundScapeRenderer/ssr/actions/runs/5269790198

This includes libfmt.dll but there might still be missing DLLs. Can you please check if it works?

HaHeho commented 1 year ago

This includes libfmt.dll but there might still be missing DLLs. Can you please check if it works?

I tried the following two executables. I had to run them via PowerShell, since running them via double click immediately closes the opened terminal without a chance to see the error message. This behavior should be improved somehow, so that a naive Windows user is not entirely lost with what might be going wrong.

PS > & .\ssr-brs.exe
       ___
      /  ___
  ___/  /  ___
    ___/  /    SSR (SoundScape Renderer) 0.6.0-27-gbc9a132
         /     renderer type: BrsRenderer

Website: <http://spatialaudio.net/ssr/>
Contact: <ssr@spatialaudio.net>

Copyright © 2016 Division of Applied Acoustics, Chalmers University of Technology
Copyright © 2014 Institut für Nachrichtentechnik, Universität Rostock
Copyright © 2012 Quality & Usability Lab, Telekom Innovation Laboratories, TU Berlin

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
PS > & .\ssr-binaural.exe
       ___
      /  ___
  ___/  /  ___
    ___/  /    SSR (SoundScape Renderer) 0.6.0-27-gbc9a132
         /     renderer type: BinauralRenderer

Website: <http://spatialaudio.net/ssr/>
Contact: <ssr@spatialaudio.net>

Copyright © 2016 Division of Applied Acoustics, Chalmers University of Technology
Copyright © 2014 Institut für Nachrichtentechnik, Universität Rostock
Copyright © 2012 Quality & Usability Lab, Telekom Innovation Laboratories, TU Berlin

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Error loading HRIR file: apf::load_sndfile(): "PkgData/default_hrirs.wav" couldn't be loaded!

For the latter, there is a problem with the path of the resource files. They are located in ../PkgData/ relative to bin/ssr-binaural.exe. By moving the contents of bin/ one directory up, I get a similar error to ssr-brs.exe above.

PS > & .\ssr-binaural.exe
       ___
      /  ___
  ___/  /  ___
    ___/  /    SSR (SoundScape Renderer) 0.6.0-27-gbc9a132
         /     renderer type: BinauralRenderer

Website: <http://spatialaudio.net/ssr/>
Contact: <ssr@spatialaudio.net>

Copyright © 2016 Division of Applied Acoustics, Chalmers University of Technology
Copyright © 2014 Institut für Nachrichtentechnik, Universität Rostock
Copyright © 2012 Quality & Usability Lab, Telekom Innovation Laboratories, TU Berlin

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
qt.qpa.plugin: Could not find the Qt platform plugin "windows" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
umlaeute commented 1 year ago

just to chime in: in my experience, the ntldd (resp ldd) method words nicely for gathering all the dylib dependencies that are encoded in the import section of an executable - because that is what ntldd outputs.

if some binary loads optional functionality via plugins, this method is bound to fail, that's why it doesn't include Qt platform plugins or similar.

mgeier commented 1 year ago

Great, it looks like we're making progress!

I have used the windeployqt tool in 2d258b71e513036b891b5f00ccab108ebdb66467, which should take care of the Qt platform plugin.

And I've used ../PkgData in 7e0901214cdb601d2a8d71b313149605a09aaa8c, but I don't know if the path should use a slash or a backslash. And I don't know whether the directory structure makes sense for the installer anyway. We can also put everything into the same folder ... or whatever. Just let me know which directory names I should choose.

The latest artifact should be available shortly at https://github.com/SoundScapeRenderer/ssr/actions/runs/5280859728?pr=352

HaHeho commented 1 year ago

The latest artifact should be available shortly at https://github.com/SoundScapeRenderer/ssr/actions/runs/5280859728?pr=352

The renderer and GUI now opens via double click in file explorer. YAAY.

Loading a config file by executing e.g. .\ssr-binaural.exe ..\Scenes\live_input.asd in PowerShell worked as well. NICE.

Even rendering a complex scene file with multiple long BRIRs in ssr-brs.exe worked without any noticeable artifacts at a JACK block size of 128 samples. AWESOME.

mgeier commented 1 year ago

Thanks @HaHeho for testing, this is great news!

I have stripped the .exe files, which makes their size much more manageable (1.5 MB instead of 44 MB).

Now everything together is about 90 MB (about 50 MB compressed), which is still quite big, but I guess it's OK for now.

The latest artifacts are here: https://github.com/SoundScapeRenderer/ssr/actions/runs/5299076783/jobs/9591819774?pr=352

I hope they still work.

I'm curious whether the browser GUI works as well ... @HaHeho can you please try this (https://ssr.readthedocs.io/en/latest/browser-gui.html) when you have some time?

Now the main thing that's missing is the installer. @chris-hld would you like to tackle this?

I would like to merge #155 soon and then make a new SSR release.

If we have an experimental Windows installer already at that point, we can include it, otherwise we can make another release whenever the Windows installer is ready.

I had to run them via PowerShell, since running them via double click immediately closes the opened terminal without a chance to see the error message. This behavior should be improved somehow, so that a naive Windows user is not entirely lost with what might be going wrong.

I don't know what's the typical solution in this case, but maybe we can configure the installer so that it keeps the terminal open after the SSR is finished?

Or we create a batch file that starts the SSR and waits for a key press afterwards?

HaHeho commented 1 year ago

The latest artifacts are here: https://github.com/SoundScapeRenderer/ssr/actions/runs/5299076783/jobs/9591819774?pr=352

I hope they still work.

I tried the same example as yesterday. As far as I can tell, there was no difference, so they seem to be working fine.

I'm curious whether the browser GUI works as well ... @HaHeho can you please try this (https://ssr.readthedocs.io/en/latest/browser-gui.html) when you have some time?

I ran .\ssr-binaural.exe --websocket-server -vvv (and other ssr-variants), and always end up with the same result. The renderer starts just fine, but dies as soon http://localhost:9422/ is accessed via the browser. There is no indication of an error in the terminal log. The last lines are from the initialization.

Starting WebSocket server with port 9422
Floating control panel is used, scene menu will not be shown.
mgeier commented 1 year ago

Thanks for testing!

It looks like the problem is with serving the files via HTTP, before even trying to connect via WebSocket.

I guess http://localhost:9422/test will give the same behavior.

It is unfortunate that serving the files doesn't work, but I wouldn't call it a blocker if the WebSocket connection itself works.

Can you please try if it works if you open PkgData/websocket_resources/index.html directly in a browser. Or if you open ssr-test-client.html and click "connect"?

Also, for completeness, it would be interesting to check the FUDI server as well: https://ssr.readthedocs.io/en/latest/network-fudi.html

HaHeho commented 1 year ago

I guess http://localhost:9422/test will give the same behavior.

Yes, it gave the identical behavior to described above.

Can you please try if it works if you open PkgData/websocket_resources/index.html directly in a browser.

Same behaviour, renderer dies without comments.

Or if you open ssr-test-client.html and click "connect"?

Same here. After clicking "connect" it shows "WebSocket connection closed. Code: 1006" in the browser.

Also, for completeness, it would be interesting to check the FUDI server as well: https://ssr.readthedocs.io/en/latest/network-fudi.html

A quick test with muting and muting a couple of sources as well as setting binaural head rotation and rotation offset, was working as expected.

mgeier commented 1 year ago

Thanks for testing @HaHeho!

It looks like both HTTP and WebSocket connections lead to the same error.

I have no clue what to do here ... I hope somebody has an idea how to debug this.

It's great that the FUDI interface works, though!

Both interfaces are based on ASIO, so the socket connections should work fine in general.

@chris-hld Did you try this on your MXE-compiled version? I guess the 3D GUI is not built, but the WebSocket connection seems to be enabled by default?

mgeier commented 1 year ago

I have re-based this to the latest SSR release and have added the new ASDF library.

Artifacts are here: https://github.com/SoundScapeRenderer/ssr/actions/runs/5490817426?pr=352

chris-hld commented 1 year ago

Thanks for testing @HaHeho!

It looks like both HTTP and WebSocket connections lead to the same error.

I have no clue what to do here ... I hope somebody has an idea how to debug this.

It's great that the FUDI interface works, though!

Both interfaces are based on ASIO, so the socket connections should work fine in general.

@chris-hld Did you try this on your MXE-compiled version? I guess the 3D GUI is not built, but the WebSocket connection seems to be enabled by default?

I don't really have access to a windows machine at the moment, but I thought I tried at some point. It seems that I had to manually set "D_WEBSOCKETPP_CPP11THREAD", and I referenced an issue in my CMAKE. I will try to find a machine and run some more detailed tests on it

chris-hld commented 1 year ago

@mgeier The MXE version websocket works as intended.

mgeier commented 1 year ago

I have installed VirtualBox and tested this with a Windows 11 image.

Now an installer is created with CI: https://github.com/SoundScapeRenderer/ssr/actions/runs/6317485071?pr=352

Installing and uninstalling works smoothly, and I can start the SSR via the start menu links. However, there are Qt-related error messages when trying to open a scene.

I could also reproduce the problem with the WebSocket interface: on any connection attempt the SSR crashes without any error message.

@chris-hld

It seems that I had to manually set "D_WEBSOCKETPP_CPP11THREAD"

Yes, thanks, I have also found that by reading the source code. Without it, it wouldn't compile.

The MXE version websocket works as intended.

It's good to know that it works when cross-compiling, now we only have to find out how to make it work when compiling with MSYS2.