Support for multiple client audio devices

[pkubat]

First great work Tobias!

In order to support both phone audio (remote) and also data (PSK31, FT8, etc) it would be helpful if there were the ability to have the local client support two (or maybe more) audio devices. One would be the mic and speakers for phone and the loopback adapter for data at the same time.

The workaround to this would be two local clients and two different configs. Although this will create twice the network traffic (I suspect, though have not ran a trace to confirm).

Thoughts?

[dh1tw]

In principle, the architecture of remoteAudio allows several audio sinks to be registered to the audio router, which is the final component at the end of an audio chain. Frankly speaking, since the same can be achieved by simply running two instances of remoteAudio, I would prefer to give other features a higher priority.

If you are concerned about bandwidth, you could add a local nats-server at your house and cluster it with the nats-server at your station. This will only duplicate the traffic in your LAN. The beauty of delegating the network to nats is that it allows you to create resilient and highly available networks without the need to ever touch remoteAudio. Our remote setup consists of a cluster of 4 nats-servers.

[pkubat]

I agree that most of the items have should have a higher priority. I also think the use case here needs to be thought through a bit more. I think it would be a better user experience if remoteAutio itself presented an audio device to the OS, then users could select "remoteAudtio" as the sound card in the software (fldig, jtdx, etc). I know this increases the scope, but long term a much better setup with fewer moving parts. I will continue to work this through and update here.

Also, how do you want feedback on your other features. I'd be interested in helping out.

[dh1tw]

yes, presenting a direct audio interface into the OS would definitely be the best user experience. Unfortunately, I haven't found a proper way how to do this. Similar to Virtual serial ports, it looks like (especially for Windows) drivers need to be signed. I found (virtual) native driver SDKs, but they are quite expensive. For the time being, I'm using Virtual Audio Cables for connecting remoteAudio to applications like WSTJ-X. If you have a better idea, please let me know! Contributions are very welcome!

[pkubat]

Thanks. My initial research was the same. I'll keep thinking and looking for solutions. So maybe this is part of a longer-term milestone? (which was you first comment)

The cluster and two clients is a good enough workaround for now.