[Feature request] Android tv / Raspberry pi port.

[ghost]

Is your feature request related to a problem? Please describe.
I got a non-patched switch not long ago and it came without a dock. The official ones cost like a lot of money and this could be the perfect open source alternative.

Describe the solution you'd like
If you could develop an android tv port, or even a raspberry pi one, you could have an alternative for those occasions that you need a tv output.

Describe alternatives you've considered
This also could be resolved with a laptop but with something like a raspberry pi would be super handy.

[exelix11]

Yes, i've been considering (and even tried) a raspberry pi port. Unfortunately the USB lib i'm using doesn't support the CPU architecture, i'm considering trying to port that lib or writing a clean room native implementation for just the USB client part but it's not a top priority thing rn, think will try to do it eventually.
In theory it should work on a raspberry pi 4 as iirc it has an arm64 cpu and it should be supported but don't have one to test.

I think TCP Bridge mode should work fine on raspberry pi but you need to selfbuild the client as it won't launch due to libusb errors even if not using it.

About android idk, don't have an android tv device and not sure if you can even use .net core on android so it would mean re writing the client in another language which is not great for maintaining it. Also android platform is more limited than windows/linux and not sure how would low latency mode work.

About that, keep in mind that sysdvr isn't meant to be a dock replacement due to limitations in the os, glad it works for you that way but i'd not consider it an optimal setup.

[ghost]

In theory it should work on a raspberry pi 4 as iirc it has an arm64 cpu and it should be supported but don't have one to test.

Me neither :(

I think TCP Bridge mode should work fine on raspberry pi but you need to selfbuild the client as it won't launch due to libusb errors even if not using it.

I though about that, but I dont have the network activated in my switch at the moment. Also, presumably, it wont have the same latency of the usb for real-time playing.

About that, keep in mind that sysdvr isn't meant to be a dock replacement due to limitations in the os, glad it works for you that way but i'd not consider it an optimal setup.

Works for the casual split screen play when a friend comes to your place, I personally don't use the docked mode that much and paying 90 euros for a nintendo one is not worth it.

[exelix11]

I though about that, but I dont have the network activated in my switch at the moment. Also, presumably, it wont have the same latency of the usb for real-time playing.

Actually a lan connection can perform better than usb cause drivers and USB stacks are less consistent and Sysdvr doesn't use an optimal protocol due to limitations for cross compatibility.

[ghost]

Well maybe if you develop the raspberry port with a custom solution you could resolve that. It will be awesome.

[exelix11]

Unfortunately time is not free :P and I'm busy irl in this period. I'm definitely going to give raspberry pi port a second try but not too soon. About Android idk, probably not.

[ghost]

I appreciate you doing this in your free time, let my buy you a coffee after i gather a bit of money hahah.

[exelix11]

Good news, built libusb for arm and it works, will be using that starting next release. Also submitted a PR to include this change in libusbdotnet.

Tested on my pi 3 and sysdvr via usb works, mpv is laggy, you'd need to find a way to use it with omxplayer cause it's gpu accelerated. On pi1 and zero it won't work cause dotnet doesn't support their cpu.

[SilentNightx]

This would be great to incorporate into https://github.com/SilentNightx/VitaDockPlus especially since I already got automatic RCM injection ready for the next release for the many who have a hacked Vita and Switch. Don't know if it would ever have low enough latency to play since you say on the readme the latency is generally 1s but it would still be neat.

I attempted compiling libusbdotnet using your fork for arm32 but there were build errors I didn't know how to solve. If the uvc version ever got finished that would work as well.

[exelix11]

You can actually use low latency mode and have a playable level of latency without streaming audio.
A few problems with your idea:

• This uses .net and that's not compatible with the pi 1 and zero CPUs
• 500ma aren't enough to charge switch while playing, battery will discharge slowly or stay at the same level depending on the game. Even without playing charge would be pretty slow
• mpv on raspberry doesn't have gpu acceleration, you'll have to figure out how to configure omx player both in rtsp mode and by piping output via stdin in low latency mode, you'll need to make sure to disable any caching to get best performances.

Unfortunately the people at libusb haven't merged my PR so will probably add my libusb as a submodule in the repo for ease of compilation, in the meantime if you want i can send you a built nupkg

[SilentNightx]

1. I know, it would still be neat to have on the Pis that can run dotnet. I can still include it in the image without creating multiple images for multiple Pis.
2. USB hubs can mitigate this.
3. No need for MPV with VitaDock+ it already has a hardware accelerated video pipeline through FFMpeg + FFplay that works across all Pis.

Great to hear that low latency can be achieved! If you can send that build I can maybe incorporate this in the next release image with credits of course.

[exelix11]

Updated dependencies and provided prebuilt nuget packages, now self-building it should be easier. Either way here's a built that should support arm
netcoreapp3.0.zip i have not tested it due to lack of time, let me know if it has any issues.

[SilentNightx]

Couldn't implement it into the new VitaDock+. It did work but every few seconds there would be a glitch in the stream when using the RTSP USB or STDOUT methods. Didn't try with MPV or RTSP over network. With STDOUT to FFplay with hardware acceleration it would have been playable if it weren't for the glitching.

[exelix11]

Mh not sure, could you try increasing the priority of the client ?
Could also be an usb bus bandwidth problem, iic on the Pi the usb bus is shared with the lan adapter. Does tcp bridge play fine ?

[exelix11]

The just released 5.0 version brings 32-bit arm support. Note that additional configuration with custom ffmpeg decoders may be needed to run smoothly on the raspberry pi.