We did a reasonably successful Flock session this AM. One concern that I have is that our leader computer is connected to the internet with only “reasonable” upload (15mbs). I was wondering if it was possible to run the “server”/“host” end on a cloud service like AWS, GCP or Azure? The benefit would be that some of those server options have very high bandwidth and CPU. If its something you’re looking at, we’re happy to be a tester.
Hey @Deighton_NFS , thanks for the feature request! I’ve added it to the list. Out of interest, what are the bandwidth options in your area? Is it possible to upgrade bandwidth with your internet provider and if yes, what is the incremental cost - is it expensive to do so? Another thought… is there someone else in the choir who has much higher upload, e.g. 100mbps?
Another question… does your provider impose data limits or is it all you-can-eat for the monthly fee subject to the bandwidth limits?
Many home internet providers, especially cable (i.e. comcast/xfinity), have very limited upload speeds. Verizon FIOS is more “balanced” up/download. Also, many non-urban internet providers are monopolies, and utter crap (ex: Cape Cod).
1 Like
Comcast is rolling out monthly limits (read here). That said, I don’t think TOTAL monthly limits are much of an issue… its the speed that the issue… and the reliability of those speeds.
1 Like
Not that you’re necessarily looking for design/architecture advice on running on AWS… but I’ll share some ideas. Much of this is based on my experience trying to run Jamulus on AWS. First, my suggestion is to run on Linux: 1, it cheaper; 2, support for multi-threading is much better/easier. My suggestion is that whatever you do on a server/cloud hosted version, you don’t build a GUI you expect anyone to use on AWS. Getting to a GUI on AWS is non trivial, while getting to a command line is quite easy. My view is that you should make the server portion simply something that is “started”, and all control and settings are performed through the choir host application (exactly as it is today, except that it would be “speaking” to a server that is in the cloud). Opening ports through the AWS firewall is no-trivial, so either have the central Flock server manage this connection (i.e. the server reaches out, by default, to the central Flock server to start the connection). Another scenario would be a web GUI to manage central settings. Broadly the idea would be that this server does as little as possible other than the very bandwidth intensive (and presumably CPU/memory intensive) work of accepting all the inbound audio streams, consolidating them, and sending them back out (including for the choir director).
1 Like
Thanks - all comments and advice are very welcome! Please keep the ideas and comments flowing. What you say makes perfect sense. The Flock architecture we’ve designed should be able to support this even though there are some components of that architecture which are not yet built.
1 Like