w3axl / python-radio-console Goto Github PK

Tracking aiortc/aiortc#701 for memory leak issues related to aiortc/PyAV

This currently manifests as a ~1GB/day memory increase per radio daemon running. Workaround is to restart the daemons to clear memory usage.

Add the ability to select specific audio devices to the client.

Should be possible based on this example

A configurable list of string lookups to translate short text strings on the radio to longer, full channel texts on the console. This would be specified per radio in the config json file.

For example:

"chan_lookup": [
    {
        "radio_text": "z1 ch1",
        "chan_text": "Dispatch Channel Main"
    },
    ...
]

It appears that XPR4550s do not auto-report statuses or channel texts via XCMP. This prevents basic operation of the radio with the console.

When louder samples from the speaker are playing, there is occasional popping and clicking. This is not clipping, and is likely something to do with the mu-law encoding/decoding algorithms in the speaker audio chain.

Several items to improve the current implementation of the radio buttons

• Switch to a row of 5 soft buttons with labels
• Pull button names from XTL O-heads, OR
• Pull button names from user-defined list in radio config entry (for control heads without button text)

These changes should allow for more flexibility in user programming as opposed to the current hard-coded button setup.

Currently, if an XCMP-controlled radio powers off or disconnects, the entire console crashes with a network error. For certain use cases, radios can be turned on/off at random and the console should survive through this.

Suggest updating the connection system to gracefully handle disconnects, as well as to allow for polling/automatic reconnection when a radio comes back online.

WebRTC connections should automatically reconnect under the following conditions:

• connection failure of the ice pair
• disconnection due to RTT time exceeding limits (added in 0d9cf00)

The following are notes to self on how to do this:

https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/restartIce

RX audio from most radios will be flat with no AGC processing.

A very basic configurable AGC would be handy. This could be implemented on the client side to reduce CPU processing load on the server.

When talking on repeaters, I've noticed that occasionally the console will stay muted when the repeater is still transmitting after dropping TX. I'm assuming the RX state is getting missed on the SB9600 line when commanding PTT to be released.

I can only connect to my radios on my local machine and not a client machine I believe it is due to websockets not being secure. Am I doing something wrong?

Eventually, multiple client connections should be supported. If nothing else, the old client connection should be booted off when the new one connects.

To alleviate some of the messaging issues and hacky time.sleeps scattered throughout the SB9600 serial threads, all serial processing should move to using pyserial-asyncio

Due to audio latency, the end of transmissions can be cut off of both RX and TX audio. This is much more pronounced with TX audio from a user's mic, as the delay can be upwards of 750ms in some cases. A PTT dekey delay has been added, but this is still not enough and the underlying latency issues should be resolved.

I've seen a few times where TX audio output to the radio will stop after a long period of console operation. No errors show up in the logs, and a restart of the console is required to restore TX audio properly. I'm not sure exactly what's going on. Will have to monitor this for now.

XCMP control is currently broken because softkey support is missing (and I was bad and didn't include legacy interface support when I made the changes)

The XCMP interface should be updated to support the XPR5000 softkeys as well as user-defined softkeys for XPR4000 radios. This will need some editing of the config file handling routines to add options for softkey definitions.

Add support for APX radios via XCMP.

PyAudio doesn't appear to work properly on my Debian test box. Getting recurring input underflows on the speaker stream callback and no audio is heard. Could be a samplerate issue.

[03/22 12:21:56.536] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.536] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.537] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)
[03/22 12:21:56.789] (  spkrCallback  ) WARN: VHF XTL got PyAudio status: PyAudio Input Underflow (2)
[03/22 12:21:56.789] (  spkrCallback  ) WARN: Queue sizes: spkr (0), mic (0)

Add an icon to the web UI to show the encryption status of the current call.

Instead of one WebRTC stream and one websocket stream between the client and server, with complex audio mixing being handled low-level in python (a very inefficient way to do it), the following makes a lot more sense:

• One WebRTC connection between the client and server, but with multiple audio tracks
• Single mic track for microphone audio split between the radios
• Multiple speaker tracks sent back to the client
• All audio processing (mute, volume, mixing, etc) handled clientside

This will be a large overhaul to the system but should result in a much more reliable system with far less CPU overhead.

With recent codebase changes, XCMP control appears to be broken.

Additionally, softkey support should be added for first-gen TRBO radios (XPR4000 series) which do not have native softkeys. Propose that a fixed set of softkeys based on the front-panel buttons be defined and added.

Add a sixth softkey to the softkey bar. Primarily, this is to add a HOME button for XTL O/M-series radios since one currently does not exist, and it's typically needed for many UI functions.

For other radios, this allows for an additional softkey for more interfacing.

A critical part of a dispatch console is being able to multitask - and with javascript keydown/keyup handling you can only capture these events when the window is in focus. Tabbing out or clicking another window/application will dekey the radio immediately.

Using something like the gamepad API could allow for control of PTT even when window is out of focus.