jamulussoftware / jamulus

Jamulus enables musicians to perform real-time jam sessions over the internet.
https://jamulus.io
Other
997 stars 222 forks source link

Feature Request - Relay Server/client #906

Closed AndyMcProducer closed 3 years ago

AndyMcProducer commented 3 years ago

Hiya I can't see where to put a feature request, Corrados could you move this please to the right department. :)

Would it be possible to have an option to set jamulus client or server as a relay server. So say ya got a server in the USA and one in Europe, the relay would connect to a server then relay the audio and chat to and from another server. Only a single stream would be needed, we could still communicate for remote to lower or up their volumes. I see the server records so gathered there is an audio stream there to be had for relaying. They'd show as a connect in the server as say (Remote Server Us Oldies -USA) but chat could show as that person and their name somit like Us Oldies - Jackie: Hiya All.

Can you see the possibilities of this and advantages?

With it could be allowing so many slots from total for relays.

This could be done manually but added ms and complex setup for many to route a jamulus to a jamulus. Would help also to make bigger servers with split resources and with the group, mute and solo options would be pretty easy to handle. Also doing it via jamulus clients wouldn't carry over the chat.

A relay server could be run also by someone who has much better pings, meaning a much shorter route for the audio combined. It would probs make more sense having it in the server, but then maybe client to so if someone doing the relay server could then adjust volumes or even int he future having a limiter on each connected in the relay server/client.

Andy.

ann0see commented 3 years ago

Hi @AndyMcProducer! Thanks for your feature request!

I think there already was a discussion on this topic (server as relay as alternative to the multi threading approach) but it wasn't implemented since there might be too much latency and syncronisation issues. Not being able to control every participant on your own mix isn't useful and if you want to control everybody, you could just use a powerful server somewhere where the ping time is almost equal to both continents. The client approach sounds interesting and might somehow be possible via a headless client on a server which then connects to another server.

I think the problem you want to solve with this idea is that it's not easy to route audio from server A to server B?

hoffie commented 3 years ago

I'm wondering if this could just be a special, extra-fast, network-only Jamulus client which does not do any audio processing and just forwards the data between two servers. It would even be possible to relay chat messages (although it would still be noticable that they are forwarded). Such a special client could either be a fork of Jamulus, make use of Jamulus' protocol parsing as a library or it could even be implemented in any other language.

@AndyMcProducer What specific use cases do you have in mind? Having larger groups (70-80 people?) seem to be no problem nowadays (I have personal experience with up to 25 people). If latency between participants is too large, a relay will probably not help. So I suspect that you are after something else?

gilgongo commented 3 years ago

@AndyMcProducer Hi - just moving this to a discussion until we can firm it up into a defined backlog item we can implement.