Expand number of possible participants

[hwalman]

HI. I am using  JamKazam for a choir of size 30 people. We are currently able to have between 10-15 connections concurrently with good results.

Is there a way to expand that number? What is causing the limitation for the number of participants?

We figured out that the total network bandwidth consumed by JK does increase in a linear fa$on as the number of connections are added. And that the total bandwidth being used must not exceed the network bandwidth of any of the participants (particularly the upstream bandwidth which is typically much smaller than downstream bandwidth). We have had success by using the feature to limit maximum outgoing music bitrate to 128 kbps. 

Is it possible to reduce the outgoing music bitrate even further? For example, could we send only one channel of music microphone music data out from each participant, instead of doubling that data into both left and right channels (assuming that is happening now)? Possibly that channel could be copied into both left and right channels on the receiving side instead of the sending side? 

Is it possible to add a higher compression audio codec also to reduce bitrate, hopefully without adding too extra much latency or CPU usage? (I know this might be asking a lot...)

It looks like our PC's are not hitting the maximum CPU % usage most of the time (it probably sits below 50% for most participants). I am not sure what else might be limiting the participant count.

Any improvement on this front would be great since all the larger choruses around the world are currently on hold due to the COVID crisis.

Thanks,
Hans

[StuartR]

HI. I am using  JamKazam for a choir of size 30 people. We are currently able to have between 10-15 connections concurrently with good results.

Is there a way to expand that number? What is causing the limitation for the number of participants?

We figured out that the total network bandwidth consumed by JK does increase in a linear fa$on as the number of connections are added. And that the total bandwidth being used must not exceed the network bandwidth of any of the participants (particularly the upstream bandwidth which is typically much smaller than downstream bandwidth). We have had success by using the feature to limit maximum outgoing music bitrate to 128 kbps. 

Is it possible to reduce the outgoing music bitrate even further? For example, could we send only one channel of music microphone music data out from each participant, instead of doubling that data into both left and right channels (assuming that is happening now)? Possibly that channel could be copied into both left and right channels on the receiving side instead of the sending side? 

Is it possible to add a higher compression audio codec also to reduce bitrate, hopefully without adding too extra much latency or CPU usage? (I know this might be asking a lot...)

It looks like our PC's are not hitting the maximum CPU % usage most of the time (it probably sits below 50% for most participants). I am not sure what else might be limiting the participant count.

Any improvement on this front would be great since all the larger choruses around the world are currently on hold due to the COVID crisis.

Thanks,
Hans

You've certainly taken advantage of all that Jamkazam currently has to offer by getting 10-15 clients participating. Your limiting outgoing bitrate to 128 kbps for each participant is also a good idea. I think your best hope for support of additional session participants may lie in the new JK network acceleration feature that they hope to roll out in the near future. As I understand it (which could be wrong) is that each participant will connect to a geographically close central server rather than peer to peer as we do now. The music data from each participant will be gathered, combined and returned to each in ONE data stream. This should lower latency and bandwidth requirements somewhat, depending on your latency to the central server. Also the use of network accelerated routers could lower latency further. Were all waiting for this to come online to see how it might help. And help we all need because the Internet congestion is pretty bad for a lot of us, even in the same city!

[Dimitri Muskens]

>>>
There is no "central server" involved in your audio/video streams on JamKazam.
The JKZ server provides the services needed to 'make things happen' and initiate the 'handshake' between peers. During a session the app/program will 'phone home' as a 'keep alive'. Your audio/video never touches the "central server" in a session or for a session to work. This happens all between peers. (this info comes from a JKZ dev and is taken from posts on this board and from the FB-group)

Bandwidth could be your issue here. And then mainly the upload. Many have quite sufficient download. Your 'part of the session' has to go out to your peers. If there's just three or four that for most is no problem but every peer added needs to receive your data as well. This accumulates quickly to numbers bigger than your max upload. This goes for all peers in a session. Just one sessioneer/jammer with poor bandwidth can bring a session down. (I think we've all experienced people on WiFi or with just a budget data plan dragging a session to a halt)

Also remember that bandwidth is 'sold' to you as a number in 'bits', your data size is a number in bytes, which is eight (8!) times bigger. So, where a 25mbps upload may sound like a decent number, you'll actually have to divide that by 8 to determine the data size your connection can accommodate.

Still, 10-15 peers simultaneous with good results is a pretty decent score.