Andrew S

Have you been leaving your instance on all the time, or switching it off when you're not using it? If you're switching it off you may be running out of CPU credit to support burst requirements, depending on how long your sessions are. The t2 instance types acrue credit when they are idle, which is then used to support high CPU when required, until your credit has run out. So there might be some momentary spike in CPU activity from another task, for example, and if you've run out of CPU credit the...

That's a shame. Not everyone uses (or wants to use) Facebook. Like me. Bye!

The mix controls will change depending on whether you have mono or stereo set for your Audio Channels. This may be related?

Sonobus looked so promising for high quality P2P that I did some testing. Ultimately it was a great disappointment. Taking a P2P approach made the P2P latency hugely more critical than with the Jamulus centralised approach, where the server acts as the focal point for sync. With the same clients the delay (max. 60mS for us) made Sonobus unusable whilst Jamulus was fine. On this basis we didn't do any scale-up testing with more clients. If I were doing a small number of clients, all of whom had <30mS...

Not sure you're understanding my use case. Jamulus starts up automatically when the server starts. I don't want to have to log in to start it. That way I can remotely start and stop the server (and Jamulus) as dessired. The servers are hosted on AWS so I can simply manage them via the EC2 console.

And no, there's no equivalent. Inter-process communication is dealt with in various other ways. The most simplistic is to monitor the status of a file's contents.

And no, there's no equivalent. Inter-process communication is dealt with in various others weays. The most simplistic is to monitor the status of a file's contents.

-n is required to get the task to start in task manager at boot time. There's no logged in user so it appears that trying to start a GUI causes Jamulus to fail.