Dear John, and all who responded,<br><br>thanks for your answers, esp. to John, AC0ZG, for his detailed one!<br>
<br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000">
    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).<br>
    <br></div></blockquote><div class="h5"><br></div></div>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.<br>

<br>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: <a href="https://github.com/rdp/virtual-audio-capture-grabber-device">https://github.com/rdp/virtual-audio-capture-grabber-device</a><br>

<br>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.<br>

<br>So, I welcome any suggestions how such an - call it API - as John suggests, might look!<br><br>Thanks again for your patience, John!<br><br>73, Hermann<br><br><br>