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

[Hermann]

Dear John, and all who responded,

thanks for your answers, esp. to John, AC0ZG, for his detailed one!


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).
>
>
My question was a little imprecise, my fault. Of course do I know what VAC
is, and John has correctly understood my intention in writing his last
paragraph. I am currently in the process of implementing the Tx path in
cuSDR. Doing that I have to think about things like VAC, COM etc.

I understand that the term 'VAC' is used synonymously for describing an
interface and the application Virtual Audio Cable, and that I tried to
point to. I have already something implemented in cuSDR, but before carving
it in stone, maybe its worth to have some discussion about how to exchange
data. Even in Qt we have already to libraries QMultimedia and Phonon which
are competing somehow. I was looking around trying to find other
implementations for 'VAC', and I only found this one:
https://github.com/rdp/virtual-audio-capture-grabber-device

But, it also very clear, to deal with the legacy or to get all interest
groups together is always as hard as possible. I know this only to well due
to my day job, and I don't think that we will be able to succeed on that.

So, I welcome any suggestions how such an - call it API - as John suggests,
might look!

Thanks again for your patience, John!

73, Hermann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20121216/9ba6a6d1/attachment-0003.htm>