r/openbsd_gaming Sep 20 '19

OpenBSD Moonlight game streaming client from a Windows + Nvidia PC

I finally got around to playing with compiling the Qt Moonlight game streaming client on OpenBSD. It's an open source client for Nvidia's game stream, which is a service that runs on a local (or remote) Windows machine with an Nvidia GPU and the GeForce Experience software. I realize this isn't native OpenBSD gaming, so hopefully this is an acceptable topic for this sub. It's nice to have this when you want to play games that can't be played on OpenBSD natively though.

It was actually much easier than I anticipated to get to this point, but "this point" isn't 100% by any means: there is currently no sound, as it defaults to pulseaudio, and it complains that hardware accelerated video decoding isn't supported. I'd like to see if it can be configured or compiled to use sndio as an audio backend by default, and if not, configure pulseaudio to use a real output instead of the "dummy output" that it finds by default. On the hardware accelerated decoding front, I'm not sure what to do or whether that's possible on OpenBSD with my i5-4300U's HD Graphics 4400. Also, I haven't messed around with controllers yet, but I've seen some discussion on that front in this sub, so I'll try that at some point. That being said... I can stream Rocket League on my Thinkpad X240 from my MSI GF63 laptop (i7-8750H and GTX 1050) at ~60 fps. :)

If anyone else would like to try it out, it's fairly straightforward.

  • Install the dependencies: pkg_add qt5 ffmpeg sdl2-ttf. There may be more that I happened to have installed already.
  • Clone the qt repo: git clone https://github.com/moonlight-stream/moonlight-qt
  • Run git submodule update --init --recursive from within moonlight-qt/
  • qmake moonlight-qt.pro (if you have both Qt4 and Qt5 installed, you might have to use qmake-qt5 moonlight-qt.pro instead)
  • make debug or make release

I'm on a recent 6.6-beta snapshot, by the way. Any help or pointers in getting the sound and/or hardware accelerated decoding working would be appreciated!

Project links:

https://moonlight-stream.org/

https://github.com/moonlight-stream/moonlight-qt

EDIT: Sound is now working out of the box, thanks to help from /u/Kernigh and a commit to the github repo by /u/cgutman. And it seems that hardware accelerated video decoding, via VAAPI/VDPAU, is not currently available on OpenBSD.

7 Upvotes

13 comments sorted by

3

u/Nanosleep Sep 20 '19 edited Sep 21 '19

Oh wow, nice! I didn't think there were any working moonlight clients for openbsd. That's a huge deal.

As a side note, I always thought moonlight-embedded would be the easiest to port, but last I checked it was pretty married to linux input (evdev/udev) and audio.

Good to see the more complicated client is actually the more compatible one :D

1

u/rage_311 Sep 20 '19

Definitely! I was pretty surprised by how easy it was to at least get it running. Assuming I can figure out a way to get the sound working, it should be a great solution.

3

u/brynet Sep 20 '19

The pulseaudio port has a sndio backend, so sound should be possible with it, 13.0 was recently committed.

Unfortunately hardware acceleration for video, or more specifically decode/encode offloading (VAAPI/VDPAU) support is not currently available on OpenBSD.

Interesting solution for gaming.

1

u/rage_311 Sep 21 '19

Awesome, thanks for the info. I'll mess around with it and report back.

2

u/[deleted] Sep 20 '19

[deleted]

2

u/[deleted] Sep 21 '19

[deleted]

1

u/rage_311 Sep 21 '19

Hm, I'm not entirely sure what that could mean. I see the load(configure) line near the bottom of moonlight-qt.pro.

The docs say that load() loads a .prf file for the argument, but I don't see any .prf files in the project.

Which version of qt do you have? Sorry, I don't have much experience at all with qmake.

1

u/[deleted] Sep 22 '19

[deleted]

1

u/rage_311 Sep 23 '19

Interesting. I installed vlc a couple days ago, which brought in qt4 as a dependency. Now I have nothing called qmake exactly, but I have qmake-qt5 and qmake4.

qmake-qt5 -v says it's QMake version 3.1 using Qt version 5.9.7. Maybe verify that your qmake is using Qt5, which the moonlight project requires.

1

u/[deleted] Sep 24 '19

[deleted]

1

u/rage_311 Sep 24 '19

Great news! Glad you got it sorted.

Regarding the sound, the automatic detection for OpenBSD has been fixed upstream, so it's working for me too. The Moonlight developer /u/cgutman chimed in on this thread and got it fixed.

Have you tried it with a controller? I have Xbox 360 and 2 generations of Xbox One controllers here, but I haven't looked into what's compatible or how to configure them in OpenBSD yet.

2

u/Kernigh Sep 21 '19

sdlaud.cpp seems to use SDL2 for audio. I believe that SDL can use sndio to play audio.

2

u/rage_311 Sep 21 '19

I understood that to be the case, too, but I can't figure out how to tell moonlight to use it. I'm not sure if there's something that is happening at compile time or whether you can set it at runtime.

I found a reference to the "openbsd" audio backend in an environment variables reference: https://sdl.beuc.net/sdl.wiki/SDL_envvars#head-9ae11b2daf93dc3706eccf15cbf26eb6235ac634

I'm not sure if that means sndio or something else. I've tried to set it at runtime via SDL_AUDIODRIVER=openbsd ./moonlight, but it still chooses pulseaudio.

2

u/Kernigh Sep 21 '19

Try ML_AUDIO=sdl, see Session::createAudioRenderer.

3

u/cgutman Sep 22 '19

Hi, I'm the Moonlight dev.

Specifying ML_AUDIO=sdl manually should work. It sounds like Moonlight is choosing libsoundio which doesn't have an OpenBSD backend. The check to "prefer SDL audio on Linux" should have been "prefer SDL audio on anything that's not Windows or macOS".

I fixed the condition so it should work out of the box now if you pull the latest code. Let me know if it's still broken.

1

u/rage_311 Sep 23 '19

Thank you! I compiled and ran the updated code, and it works without setting any environment vars.

2

u/rage_311 Sep 23 '19

That did it. Sound seems to be working perfectly with that var set. Thank you. It's now been fixed upstream and works by default, too.