Running AMS on WSL 1

[Emre]

1. Can I run AMS on WSL 1 as an application or as a service? Is there anything to look out for in terms of best practices?

2. What are the technical limitations that do not allow AMS to run on Windows? Would it be possible to work with Ant Media or a partner to develop a version of AMS that can run on Windows servers?

3. How can I create a push to talk api just like Mumble? Which REST methods should I use? Is it possible to create a sample page for this? (This is a good idea)

Thanks in advance.

[Burak]

1. I have been using Windows+WSL2 (Ubuntu) for 10 months. But I am running it with start.sh script. I never tried it as service. @Mohit @Yash have you tried it?

2.  To be honest, I haven't performed such a benchmark test since mine is development environment. But I haven't seen a problem with stream quality. The best way to verify it, you can create a Windows instance on the cloud and try with WSL and make a load test on it as told here:https://resources.antmedia.io/docs/load-testing

3. Actually, I am not sure if I understood correct what you want to do. If you want to share audio data between Mumble and Ant Media Server plugins may be the solution instead of REST API. Please check this for more on plugins: https://antmedia.io/plugins-will-make-ant-media-server-more-powerful/

[Connessione]

On 11/25/2022 at 11:38 AM, Emre said:

1. Can I run AMS on WSL 1 as an application or as a service? Is there anything to look out for in terms of best practices?

2. What are the technical limitations that do not allow AMS to run on Windows? Would it be possible to work with Ant Media or a partner to develop a version of AMS that can run on Windows servers?

3. How can I create a push to talk api just like Mumble? Which REST methods should I use? Is it possible to create a sample page for this? (This is a good idea)

Thanks in advance.

1. Also consider docker / virtualbox to run ant media server on windows host.

3. It seems that mumble is a desktop client so probably the performance and permission domain is different than a web application. But that said when you say push-to-talk, it is more like push-to-transmit voice. In terms of ant media based technologies  (WebRTC or RTSP), an application first makes a connection to the server and then transmits audio.

You can always wrap these steps into one functionality via GUI and call it push-to-talk. In the  background it is actually push-to-connect-and-transmit. The other way to do this is to connect to server and always keep connection open. Then push-to-talk becomes push-to-unmute and on release of GUI you mute microphone.