[hpsdr] KISS 1.1.24 used with VAC from digital program?

[John Marvin]

  Hermann,

Over time a large number of software applications were written for 
interacting with "HDR's" (Hardware Defined Radio :) ). These included 1) 
connections via serial ports so that software could control a radio, or 
a radio could control software (e.g. CAT control), and 2)  connections 
via audio card inputs and outputs to process demodulated audio (i.e. 
input to the computer) or transmit audio. The most common example of 
these are applications that implement one or more digital modes.

With SDR's the "radio" is an application. In order to take advantage of 
the already existing large number of applications for hardware radios 
people chose to leverage the already existing interfaces to these 
programs, i.e. serial ports and audio ports.  With hardware radios these 
connections were made by real serial cables and real audio cables.  In 
order to connect a software radio to these applications drivers were 
written to implement virtual serial cables and virtual audio cables. A 
virtual serial cable driver provides two serial ports (COM ports in 
Windows terminology) that are "connected" within the driver to pass data 
from one to the other. A virtual audio cable provides a single audio 
"device" with input and output that are connected together within the 
driver to pass data from input to output. Think of a sound card with 
cables connecting the Left line out to the Left line in and the Right 
line out to the Right line in.

These virtual devices allow one application to "talk" to another without 
having to actually use a hardware loopback (i.e. like I described above 
for an audio card). When we refer to VAC support we refer to the ability 
to send demodulated audio to a virtual audio cable IN ADDITION to being 
able to send it to a "hardware" audio output. Note that if someone has 
the VAC driver installed on there system they show up in any list of 
available audio outputs and inputs. I say "IN ADDITION" because a user 
usually wants the primary audio sent to an audio output that they are 
listening to, since they may be looking for both voice and digital 
contacts. Once they see something they are interested in they may start 
another application to listen to the other side of the VAC to process 
that audio in some way. For example there is no one single wonderful 
application that knows every digital mode and provides the optimal 
implementation of each mode.  So it sometimes requires the operator to 
listen to the transmission (and observe it in the waterfall) in order to 
try to identify the mode before choosing the application that would be 
used to receive it.

Receiving audio via VAC gets even more complicated since it usually is 
done in order to transmit, and that usually requires that the program 
sending the audio also needs to control at least the PTT and perhaps the 
transmit frequency.  This usually requires a virtual serial cable in 
addition to a virtual audio cable.  The setup can get somewhat 
complicated, especially for first time users.  Obviously you have to add 
transmit capability to CuSDR before you can even consider this, but you 
should be thinking about it if you plan on adding "VAC" capability.

So, essentially it is called "VAC" capability since the VAC driver is 
used to implement the connection between the software radio and other 
software applications. There are other components of this feature that 
make it more useful. For example PowerSDR has DIGL and DIGU buttons in 
addition to LSB and USB buttons for indicating SSB demodulation.  This 
has the advantage that each button typically remembers the last settings 
for that mode (e.g. filter parameters, AGC etc.) so you can set up what 
makes sense for a digital mode and not have it interfere with your 
settings for the equivalent voice mode, which may not be approprite for 
digital modes.  It also allows the software radio to allow settings like 
only send audio when the DIGL or DIGU mode button is being used.  There 
are other features like allowing thepushing of PTT on the mike to 
override the  PTT on the digital mode, i.e. the transmit  audio would 
then come from the mike rather than the VAC input. Other options include 
allowing the sending of the direct I/Q data to the VAC for programs that 
know how to deal directly with I/Q data.

I would highly recommend playing with the VAC capability on PowerSDR 
before adding such capability to CuSDR.  You should actually install a 
digital mode program (e.g. fldigi, WSPR, etc.) and make it work with 
PowerSDR. That would give you a much better feel for what is involved, 
and you can then understand what is needed and perhaps how things can be 
done better. Note that the VAC driver is not free and has to be purchased.

Personally, I think it is time to start looking at something better than 
having to deal with virtual serial and virtual audio cables.  These were 
done in order to leverage existing software while SDR was new.  But they 
are kind of archaic methods that should be replaced as SDR gets more 
popular.  I think it would be great if a group of people consisting of 
SDR authors, digital mode software authors, etc. got together and 
defined a new interface which makes it possible to connect these 
programs together without having to go through a kernel driver in an 
easier and even more powerful way.  I think it can be done in a way that 
allows for a graceful transition, so that SDR's that don't implement the 
new interface can still connect to the new/modified programs via an 
intermediary program that implemented a VAC to new api connection, and 
also allowed SDR's that only implemented the new interface to talk to 
old programs by doing the reverse (i.e. an external program or built 
into the new api library for compatibility). This would also allow HDR's 
to continue to interface with applications that were written to only 
support the new interface. The underlying transport could be a variety 
of things like shared memory (lowest latency), local sockets, and even 
IP sockets (higher latency but allows for incredible versatility). The 
applications wouldn't have to know what the actual transport is, 
although it might have to provide the mechanism for configuring it (or 
overriding automatic configuration).

John
AC0ZG

 1355611016.0