peerJS audio calling between DJ Controls

[Lovinity]

Incorporate peerJS in DJ Controls.

• [x] Modify the manage DJ Controls window to utilize the new makeCalls, answerCalls, silenceDetection, and recordAudio hosts options. Prohibit having more than one host with silenceDetection or recordAudio being true. Warn when setting a host's silenceDetection to false (that unless they set another host's silenceDetection to true, silence detection will no longer be present) or recordAudio to false (that unless they set another host's recordAudio to true, the system will no longer make audio recordings of the radio station).

- [ ] Transform DJ Controls to always show the options icon regardless if the client is an admin. However, hide access to all buttons / management which require admin. REJECTED: using separate audio options / icon instead

• [x] Add a new button in options audio settings menu on the WWSU Operations module that allow you to change the input device and output device of peerJS audio calls on that specific DJ Controls. Should default to whatever the OS sets as the default devices. Changing the output device should require director authorization. But changing the input device / microphone should not require authorization. Settings should be saved locally to the electron application. All DJ Controls should have access to these settings regardless of makeCalls nor answerCalls settings.

• [x] Split the sports button in the WWSU operations model into "sports" and "sports remote" buttons; get rid of the remote broadcast checkbox in the go sports dialog.

• [x] Add a small indicator somewhere in the WWSU Operations model that is always visible and shows the status of peerJS audio calls. Perhaps just use a small circle. Green = successful and active peerJS audio call. Yellow = active connection, but input volume has been below -15dB for 5 or more seconds. Red = lost connection and attempting to re-connect. Gray = no connection and not attempting to connect.

• [x] When requesting to go remote or go sports remote, reject the request with an error if the DJ Controls host does not have makeCalls set to true. Otherwise, a window should pop up as normal requesting the show host/name for remotes and the sports being broadcast for sports broadcast. Window should also prompt the user to establish a peerJS audio call with the appropriate DJ Controls. The window should also include a VU meter which shows audio levels for the currently configured microphone, and a dropdown to change the microphone setting. Have the user choose which DJ Controls host to establish the connection to. Available options should be authorized DJ Controls hosts with answerCalls set to true and are reporting online. After selecting a DJ Controls, keep the window open while attempting to start a peerJS audio call with that DJ Controls. Try for 30 seconds. If connection fails or times out, show an error and keep the window open to allow the user to try again or another DJ Controls. Do not allow to proceed to starting the broadcast until a peerJS connection is made. Once a connection is made, automatically start the broadcast.

• [x] Whenever requesting to return from break/halftime/disconnected in remote or sportsremote, if a peerJS audio connection is not present, DJ Controls should open a window displaying the connection status and prompting the user to check their network connection or establish a connection with another DJ Controls before DJ Controls actually begins returning to the broadcast. Once a connection is established, proceed returning automatically.

- [ ] All DJ Controls should use WWSU-${host fingerprint} as their peer ID. REJECTED: Peerjs does not support this. Instead, DJ Controls will report the peer ID to a server endpoint.

• [x] During a peerJS connection, the DJ Controls who initiated the call should be transmitting audio from its microphone to the DJ Controls selected when connecting. Use Opus encoder or another very effective encoder. Use 96kbps stereo audio quality. (Not possible at this time with Peerjs). Use automatic volume adjusting to ensure there is no clipping and that audio levels are above -15dB. But do not go above 150% 300%. Volume increases should be gradual over a period of 5 seconds. Volume decreases because of clipping should be immediate. DJ Controls should automatically and infinitely try to reconnect whenever the connection is dropped unless the user clicks a cancel button. The first attempt should be immediate. Subsequent attempts should be every 3 seconds. Reconnect attempts should time out after 5 seconds. If the disconnection lasted several seconds, automatically send the broadcast to break.

• [x] The DJ Controls that was selected from the connect dialog box should automatically accept an incoming peerJS call, but ONLY if answerCalls is true for that DJ Controls host, and if the calling host exists in WWSU's hosts table and has makeCalls = true. If any of those conditions are not met, reject the call (or just don't answer it).

• [x] The DJ Controls on the receiving end of the peerJS audio call should ONLY play the receiving audio to the configured output sound device when the current WWSU state is remote_on or sportsremote_on. Otherwise, it should be muted.

• [x] DJ Controls should disconnect / close the peerJS connection automatically when WWSU goes into any state other than remote*, sportsremote*, automation_remote, or automation_sportsremote. DJ Controls should remain connected / continue trying to reconnect when in disconnected state or any other sportsremote or remote state.

• [x] DJ Controls should disconnect the PeerJS call when going to break, but reconnect when returning, to ensure a fresh connection.

• [ ] Test all of the above functionality.

[Lovinity]

PeerJS calls are currently causing CPU to spike, and sometimes audio is not actually being broadcast out.

[Lovinity]

Although a majority of the features have been implemented in DJ Controls, this feature is being marked as UNSTABLE; it is too time consuming to fix this at this time considering 6.0.0 has a deadline

[Lovinity]

Peer.js continues to give us issues. It is now too late to implement a stable Peer.js in DJ Controls.

Peer.js and remote broadcasting capabilities will be disabled in version 6.0.0

The current plan is to use Kamailio server-side and sipjs client side. However, be aware Kamailio use will require an open UDP port/ports on the WWSU server.

[Lovinity]

I'm giving this another go using SkywayJS, which is a derivative of PeerJS with a more dedicated STUN and TURN server. They give us a generous 500GB of TURN per month, plus 500,000 STUN signals per month. That's more than plenty for WWSU use and then some.

Currently running a lot of tests. SkywayJS so far seems very reliable in terms of connection reliability.

[Lovinity]

SkywayJS seems promising. The main issue is sometimes when the network goes bad, there will be a lot of jitter, which will remain even when restarting the audio call. This will need addressed before SkywayJS becomes a feasible solution.