Next features

[dh1tw]

Hey everyone,
the next holiday season is around the corner and I'm planning a bit on the improvements I want to make to my projects. As for remoteAudio, I was thinking about reworking mainly the audio input/output selection. However, a few more ideas have accumulated which I would like to share with you. I don't think that I will have sufficient time to implement all of them, but maybe somebody would like to jump in and help out as well.

Below are the ideas for improvement I had so far

Dynamic Audio Input/Output Device selection:
Right now, the audio input / output devices have to be specified either in the config file or through pflags. Once started there is no possibility to change the input / output device anymore. Therefore I would like to add support for the dynamic selection of audio devices during execution. Changing audio devices should be possible through the User Interface and through the REST API. I think even output on multiple devices should be possible.

Simplifying Audio Input/Output parameters:
I have the feeling that 99% of the time the default values of the input / output audio devices (as shown when calling remoteAudio enumerate would perfectly do the job. I have seen very little users actually tweaking these parameters. So in order to reduce complexity and make remoteAudio more user friendly, I thought about removing or at least hiding the parameters:

• samplerate
• device-latency
• hostapi

Simplifying frame-length parameter:
Currently, the length of one audio frame (frame-length) has to be specified in bytes. The value can be divided by the sampling rate for determining the actual length of the audio frame. I think it might make more sense to directly specify the length in milliseconds. For the opus Encoder, the sampling rate must be 48000 and only a couple of specific frame-lengths, ranging between 2.5ms and 60ms are accepted. So, why not directly specify the frame-length in milliseconds?

Record / Replay support:
I already started some time ago to add a WAV audio sink and WAV audio source. I thought it might be cool being able to directly record audio to file. Another implementation form would be the support of DVK which might be useful for Contesters.

Standalone App / GUI:
Go is a backend language and is not intended for creating applications with user interfaces. So far, the most popular way of embedding a user interface was to add a built-in HTTP server. During the last two years, a few GO based GUI frameworks have started to receive traction. Namely The Wails Project and the Fyne toolkit. My idea from the beginning was that remoteAudio should be a service running in the background and being controlled (through the REST interface) by a 3rd party program. However, I recognize that a large group of users would prefer a version of remoteAudio with a clickable icon and a self-contained GUI. Now with two decent alternatives, it would actually be possible and realistic to add a self-contained GUI.

Add TCP and/or UDP as transport alternative to NATS:
I personally love NATS. NATS abstracts way the network from the application. If you want, NATS allows you to set up complex, redundant, secure network topologies, but it's not necessary. Having the nats-broker running somewhere between your server and your client on a small embedded device can already be sufficient.
However, I recognize that there are still a lot of folks who either don't have the skills or just don't want to deal with NATS. Therefore support for plain TCP and/or UDP could be added to remoteAudio. It actually shouldn't be too complicated since the transport layer is quite well separated from the actual functionality.

Add additional Audio nodes / sources / sinks:
Incoming or Outgoing Audio is always processed in remoteAudio the same way. The Audio Chain looks like this:
Source -> Node1 -> Node2 -> NodeN -> Sink(s)
Each Source, Sink, Node has to fulfill implicitly the corresponding Interface. So far I have implemented a couple of Sources, Sinks and Nodes. For example, one node is for example a voice activated switch (VOX). Any kind of Audio Analysis or Manipulation can be done through nodes. One source I would love to see is for example a Morse Code (CW) generation for a local, low-latency side-tone.

Forward Audio into the Webbrowser:
Using the existing WebSocket, the audio frames could be forwarded into the browser for replay. From what I have read, the Audio API in browsers has actually improved significantly.

That's it! What do you think?
I would love to hear your thoughts and comments!

73 Tobias
DH1TW