Unfortunately, the current manual, while better than anything that came before it, still has many errors and omissions in it. In this case, it omits the VAC paths from the block diagram in question. Please forgive my crude scratchings:
- Capture.JPG (141.45 KiB) Viewed 4711 times
VAC, by definition, has nothing whatsoever to do with the CODEC related audio paths. The CODEC paths are quite torturous, and are well described in this topic:
https://community.apache-labs.com/viewtopic.php?f=12&t=2612Whereas the VAC audio paths are relatively simple and direct. For RX it's Thetis-->Windows Audio Devices and for TX it's Windows Audio Devices-->Thetis. No trips back and forth over the Ethernet necessary, no firmware processing required. Unfortunately the design of the VAC interface itself is quite clunky and complex, but properly set up to use the ASIO driver it is the most efficient audio path. Note that if you use anything but ASIO then the CODEC paths will be faster. Of course that should not be a problem with your MOTU interface.
It's always seemed most unfortunate that the original Hermes designers chose to provide what amounted to a custom audio interface in the external hardware design. This was before my involvement in the community, but I believe their thought processes in this area involved two concerns. The first was to maintain the audio interface in the same clock domain as the RF hardware. This has some technical merit, but is clearly unnecessary given the successful transition between clock domains that so many other audio app's and accessories manage in the Windows world. The second idea was to provide a more "traditional" user experience, i.e. a box that felt more like an regular radio. We see this latter philosophy even in today's hardware designs, most notably Andromeda. Personally I feel that this philosophy substantially limits the extensibility and functionality of the openHPSDR architecture, but as a non-developer I have little sway in the proceedings