Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio send only mode #842

Closed
JoschiCiubotaru opened this issue Jan 15, 2021 · 13 comments
Closed

Audio send only mode #842

JoschiCiubotaru opened this issue Jan 15, 2021 · 13 comments
Labels
feature request Feature request

Comments

@JoschiCiubotaru
Copy link

Feature request: Client switch to "Send Audio only"
Due to the limitation in Jamulus to send just 2 channels, I'm using two instances of the Client. 2 channels for my instrument (keybaords) with mic mixed in. In addition a Click-Track/Backing Track will be sent with the 2nd client.
BUT: With the 2nd client I also recieve the mix from the server a second time (that doesn't make any sense). To reduce traffic (from the server and to the client) I would love to see a switch (start parameter or in the GUI - I don't care) to have Jamulus Client in a "send only" mode. The Client just need to send the audio from the input.
Somehow the server must be aware of this mode.
As long as the 2 channel limition per instance exists it would improve network trafic for people who need more then 2 channels to send. Does this request make any sense?
To take the "listener mode" in account I can imagine somthing like this:
Mode: Normal (send and receive)
Mode: Listen (Receive only)
Mode: Cast (Send only)

@ann0see
Copy link
Member

ann0see commented Jan 15, 2021

I think implementing something like this is quite difficult.
You could also mute all channels which should result in almost no data being sent to your PC. You could also set the new client level to 0 and reset all channels to the new client level.

@nefarius2001
Copy link
Contributor

I think implementing something like this is quite difficult.
You could also mute all channels which should result in almost no data being sent to your PC. You could also set the new client level to 0 and reset all channels to the new client level.

Muting should redruce calculation in the Server, but not the Traffic. Ihmo

@vdellamea
Copy link
Contributor

I also think that muting in general does not influence traffic (even the mute yourself button - I think it zeroes data, but still sends).

Since this was discussed on the forum, I personally think it makes sense, although normally what is asked is the listener version (for the public). Not having read the code, I cannot tell how hard it is to implement, however clients could have a property like "donotsend" that is checked when sending out the mix. However, if in a band just one or two receive double data, I do not think is an issue from the point of view of bandwidth (server-side, although it may make the difference for a home-run server).

@corrados
Copy link
Contributor

We already had this discussion, see #160.

@JoschiCiubotaru
Copy link
Author

JoschiCiubotaru commented Jan 17, 2021

Thanks for all the comments.
Setting Volume to zero or mute a channel has no impact on data transfer. That's easy to see.
As soon as a client connects the server start the stream to the client.
@corrados the discusseion in #160 is the oposite way. My main point is about a second instance of Jamulus on the client that makes no sense to get the stream (because this comes already with the first instance).
We are 5 members in the band running with 6 instances and could reduce traffic near to 20% if the second instance of the client would just send and not receive any data.

@gilgongo gilgongo added the feature request Feature request label Feb 19, 2021
@gilgongo
Copy link
Member

Hi @JoschiCiubotaru I think the consensus is that the problem you describe does't warrant the potential size of the changes that would be needed to solve it. At least, lack of bandwidth when using Jamulus doesn't seem to a problem that's reported generally as most domestic broadband connections have more than enough unless unusually congested by other things.

@JoschiCiubotaru
Copy link
Author

Maybe then it's easier to allow more than two channels to be sent. These can still be sent stereo or mono to the server if that is an issue. Just let the user decide which channel to map to left, right or mono (and left+right to map a mono signal to both outputs). If 4 channels were possible, a 2nd instance wouldn't be needed either and the problem would be solved as well.

@hoffie
Copy link
Member

hoffie commented Feb 21, 2021

Maybe some hope for an alternative solution: I'm planning to start a fresh discussion topic regarding usage of VBR in the coming weeks. When muting all audio in the mix and using VBR the required bandwidth for receiving should be vastly reduced.

Maybe then it's easier to allow more than two channels to be sent. These can still be sent stereo or mono to the server if that is an issue. Just let the user decide which channel to map to left, right or mono (and left+right to map a mono signal to both outputs). If 4 channels were possible, a 2nd instance wouldn't be needed either and the problem would be solved as well.

Might be worth opening a discussion about that? :)

@npostavs
Copy link
Contributor

Maybe then it's easier to allow more than two channels to be sent. These can still be sent stereo or mono to the server if that is an issue.

This is implemented (at least on some platforms) if and only if your sound device has exactly 4 input channels.

https://github.com/jamulussoftware/jamulus/blob/r3_6_2/windows/sound.cpp#L226-L227

@gilgongo
Copy link
Member

@JoschiCiubotaru Are you OK with the resolution on this issue? Aspects have been discussed here #160 and there may be a forthcoming discussion on VBR.

If so please close, thanks

@JoschiCiubotaru
Copy link
Author

Maybe then it's easier to allow more than two channels to be sent. These can still be sent stereo or mono to the server if that is an issue.

This is implemented (at least on some platforms) if and only if your sound device has exactly 4 input channels.

https://github.com/jamulussoftware/jamulus/blob/r3_6_2/windows/sound.cpp#L226-L227

Thanks for your hint. I tried that with my MOTU M4. It has 4 physical inputs but 2 loopback adapters as well. Therefore this implementation does not work for me. Why is limited to exactly 4 input channels?

@JoschiCiubotaru
Copy link
Author

@JoschiCiubotaru Are you OK with the resolution on this issue? Aspects have been discussed here #160 and there may be a forthcoming discussion on VBR.

If so please close, thanks

I reviewed the issue #160 and already mentioned that my topic is the the different. It's not about listening (not sending anything) but send only when a second instance is running.

I overthought the the implementation of @npostavs and this is not the solution that will help. The reason here is, that even if I'm able to mix more then 2 channels then there is still just one fader for the other members to the control volume.

I send my talkback mic and the keys sound with 2 channels (and a dedicated fader) and the Click-Track/Backing Track with the 2nd Instance of the Jamulus Client. The 2nd Client will again get the mix from the server - wich doesn't make sense because the first client did get it already.

I'm very sorry that I can't explain it in a better way. I'm not sure if the VBR topic will cover my request. So maybe a little more details on that would be fine before I close this issue. Is that ok for all?

@gilgongo
Copy link
Member

@JoschiCiubotaru In the interests of having the issues contain actionable specs for work, I'll move this to discussion until we can firm this up.

@jamulussoftware jamulussoftware locked and limited conversation to collaborators Mar 14, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
feature request Feature request
Projects
None yet
Development

No branches or pull requests

8 participants