[Feature Request] Connect to FreeDV-GUI Without Virtual Audio Cables

[jimahlstrom]

Contact Details

It is a new general purpose interface.

Feature for this project

Background

I am the author of Quisk, a software defined radio. Quisk has had support for FreeDV for several years. I used the codec2 API to make FreeDV an internal mode of Quisk. It has its own "FreeDV" mode button just like USB. This was convenient for my users, but it didn't use the FreeDV GUI window so it lacked those features.

Currently Quisk supports the new RADE mode with the usual virtual audio cables and does offer the GUI, but it is inconvenient to use. Since it connects directly to the sound card speakers and microphone it is incompatible with other modes and requires different settings in Quisk. And my users have trouble setting it up.

Making Quisk and FreeDV work well together will require a lot of work on my part, and I would like to propose a general purpose solution that will benefit other users too. My idea is to design a new zero-configuration interface that makes it easy to connect FreeDV to Quisk, other SDRs and to classic radios that use a software TNC.

New Interface Features

• Eliminate the need for virtual audio cables.
• No configuration by the user is required.
• I write and maintain the interface as a single .c and .h file.
• It is written in vanilla C.
• The code works on Windows and Linux, and hopefully Mac.
• It connects to FreeDV-GUI so the GUI is available.
• Easy to add to FreeDV-GUI (I hope).
• It is a proposed standard so it is easy to add FreeDV to other radios.

Interface to FreeDV

To use the interface in FreeDV, call a registration function on startup, and a de-registration function on exit. This announces FreeDV to other programs on the same computer. Then call functions to advertise FreeDV's available interfaces, namely SpeakerSound, the decoded audio that should be sent to the speakers, and TxSamples, the coded audio that should be transmitted. FreeDV will need to read RadioSound and Microphone from another program like Quisk. Then within the existing sound code, call read and write functions on these four interfaces instead of on virtual audio cables or sound cards. These functions strongly resemble the normal audio functions.

To enable the interface, it might be enough to change all of FreeDV's four existing sound interfaces to "None". Or maybe there is a check box that grays out the sound interface.

Interface to Quisk or Other Programs

Quisk will advertise its interfaces, namely RadioSound, SpeakerSound, TxSamples and Microphone. For SSB, Quisk will operate normally. When the user selects FreeDV, Quisk will route RadioSound to FreeDV and use SpeakerSound for the speakers, and will route Microphone to FreeDV and read TxSamples for transmit. There is nothing for the user to configure, it just works. Note that this design replaces requests for FreeDV features that belong to the radio, such as #907, #983, #992 and #1032.

Hopefully, digital programs like WSJT-X will use this interface too.

Summary

I need to know whether this seems like a good idea and whether it might be added to FreeDV if it works as described. It is possible I missed an easier or better solution, but I for one am sick of virtual audio cables.

Jim Ahlstrom
N2ADR

VHF/UHF

No

Deprecated features

No

Non-standard compiler

No

Legal worldwide

Yes

Implementation assistance

I will write the interface code as a single .c and .h file.

Support assistance

I will support the new interface and change it as required by the ham radio community for several years.

[Tyrbiter]

Initial thoughts: this is probably going to be useful in the medium term but it will require the RADEV2 coded in C to avoid the current python libraries.

I'm sure @tmiw will have more to say about what is needed to allow this to work.

[tmiw]

Initial thoughts: this is probably going to be useful in the medium term but it will require the RADEV2 coded in C to avoid the current python libraries.

I don't think this would necessarily require a C port. From what I understand with @jimahlstrom's original post, the ask is that there should be some sort of (TCP/IP?) based interface in FreeDV that software like Quisk could connect to in order to route audio and/or CAT control.

Anyway, this request immediately made me think of https://github.com/ExpertSDR3/TCI. We did receive a request for TCI support a while ago IIRC but there weren't a minimum number of people asking for it per our current development process to escalate it further. We could either revive the original proposal for TCI or perhaps come up with a different protocol to enable this (such as VITA-49, especially since we're already supporting it in ezDV and the upcoming RADE Flex waveform).

[bluzee]

The use of virtual audio cables would have never been necessary with any SDR software or softmodem application had developers used Jack Audio. A sound server available for Linux, Mac and Windows that enables inter application audio routing.

The default audio system in most Linux systems now, Pipewire, allows for inter application audio routing regardless of whether the application uses Jack Audio or Pulseaudio. Currently the audio connections can be made using qpwgraph or the like. To make the connections from within Quisk or the FreeDV GUI would require at least listing all available audio I/O ports available rather than just listing only hardware or virtual hardware audio I/O ports. Quisk may want to disconnect from the Mic capture port and the output to the hardware audio interface, but it's not entirely necessary I don't think.

For FreeDV GUI providing more easily identifiable names to the audio I/O ports would simplify connections. Currently offered I see one combined channel named Input which is the Mic input, another combined dual channel named Output which sends TX audio to the SDR software. Then there are a couple FL/FR inputs which appear to only receive names by Pipewire so again only say input. These are the RX input from the SDR software. Finally another FL/FR pair of outputs given the same output name by Pipewire that are the decoded audio output to the hardware audio interface. All these connections can be made directly without any virtual audio device (cable). The only hard part is figuring out which goes where because there is no specific naming of the I/O ports. Once you get that sorted it's dead simple.

I had to read Jim's tutorial on his website before I could finally get the connections sorted in FreeDV GUI.

[bluzee]

Please disregard my previous comments about I/O port labels. As I bring things up in qpwgraph today I see they are all labelled. I was using Raysession previously as it is my normal session manager and it did not pick up the labels in it's patchbay.

If anyone is having problems sorting out the connections, just bring up qpwgraph.