Headset monitor and mics
-
Tony EI7BMB
- Posts: 652
- Joined: Sun Apr 09, 2017 2:31 pm
- Location: Dublin
- Contact:
Re: Headset monitor
Behringer B1 arrived this morning. I can confirm that it works just fine on the voltage supplied by the Xenyx 302 mixer . As Scott has already suggested the B1 really is flat , it sounds good and gives a nice flat "bart Simpson hair effect" on the display. I had it set up in no time at all using the previous sennheiser set up as a starting point.
Last edited by Tony EI7BMB on Wed Nov 15, 2017 12:47 am, edited 1 time in total.
Re: Headset monitor and mics
It's amazing how much mic you can get for $99, isn't it? 
-
Tony EI7BMB
- Posts: 652
- Joined: Sun Apr 09, 2017 2:31 pm
- Location: Dublin
- Contact:
Re: Headset monitor and mics
Sure is Scott
Re: Headset monitor and mics
I am concerned about the poor transmitter audio to headset operation.
K9VV Ken told me that the 7000D has improved latency and sent me the info.
I read that article and it is about latency from microphone audio to antenna on transmit. I use a Heil headset and monitor my transmitted audio on my past rigs, ICOM pros and last rig the 7600. There have been comments about transmitter audio latency in other ANAN units. I asked a local ham who has a 200 and he does not use a headset however he hooked up one and said that the delay was annoying. There has been discussion on the "Apache Community" of this and to work around it was to use a mixer to monitor direct mike audio and receive audio.
I ran an experiment to see how much latency would be acceptable and not have to use an external mixer. I used an Allen :& Heath AED 10FX mixer and a Ashley Protea NE24.24M audio processor set up in the delay function. I found that delay up to 10 ms was not noticeable, 15 ms starts to be heard but is not objectionable, and 20 would soon be annoying and unacceptable. These are my observations and your mileage will vary
I will be using the mixer monitor lash-up. Seems a shame that all of the rigs that I have had in the past had good monitor circuits. State of the art rigs come along with fantastic receiver and transmitter specs but still cannot get the simple monitor part right.
I have been spoiled with my 10 year old Perseus - best receiver that I have ever had and am looking forward to my even better 7000D Rig.
73,
Bill, WA2DVU
Potato Island, NJ
K9VV Ken told me that the 7000D has improved latency and sent me the info.
I read that article and it is about latency from microphone audio to antenna on transmit. I use a Heil headset and monitor my transmitted audio on my past rigs, ICOM pros and last rig the 7600. There have been comments about transmitter audio latency in other ANAN units. I asked a local ham who has a 200 and he does not use a headset however he hooked up one and said that the delay was annoying. There has been discussion on the "Apache Community" of this and to work around it was to use a mixer to monitor direct mike audio and receive audio.
I ran an experiment to see how much latency would be acceptable and not have to use an external mixer. I used an Allen :& Heath AED 10FX mixer and a Ashley Protea NE24.24M audio processor set up in the delay function. I found that delay up to 10 ms was not noticeable, 15 ms starts to be heard but is not objectionable, and 20 would soon be annoying and unacceptable. These are my observations and your mileage will vary
I will be using the mixer monitor lash-up. Seems a shame that all of the rigs that I have had in the past had good monitor circuits. State of the art rigs come along with fantastic receiver and transmitter specs but still cannot get the simple monitor part right.
I have been spoiled with my 10 year old Perseus - best receiver that I have ever had and am looking forward to my even better 7000D Rig.
73,
Bill, WA2DVU
Potato Island, NJ
Re: Headset monitor and mics
Bill,
The latency of every openHPSDR architecture radio, from the Hermes (10, 10E, 100), to the Angelia (100D), Orion (200D) and Orion MkII (8000 and 7000), is exactly the same. They use the same software processing in PowerSDR mRX, the same Ethernet communications protocol between the radio and the PC, the same FPGA code (with respect to audio processing), and the exact same CODEC circuitry to support mic and speaker/headphone connections to the radio. None of the radios have any advantage over the other in this respect.
Which article are you referring to? Where can it be found?
With respect to obtaining simple sidetone, there is absolutely no reason that our radios can't achieve acceptably low latency. The CODEC IC used on every board from the Hermes to the Orion MkII has a built-in, zero latency sidetone path. It is simply not utilized by the software/firmware. Similarly, for those using VAC and fully virtualized audio, the simple problem is there is no software in PowerSDR to create a low latency path from the VAC input to the MON circuit and back out the VAC interface. I've suggested it be added, but it is simply not something the developer community is interested in working on, unfortunately.
With respect to mic-to-antenna latency, and antenna-to-speaker latency, the greatest impediment was the IF passband filter implementation in PowerSDR, which was based on simple linear phase FIR filters. Such filters do provide great phase and amplitude linearity, but also exhibit relatively long latencies. In PowerSDR, when using the linear phase FIR filters, the delay through them in milliseconds is defined by filter length divided by 48 (filter length is erroneous labeled as filter size in the setup window, and the factor of 48 comes from the 48KHz audio processing sampling rate used internally by PowerSDR). Even a filter of a relatively minimal length, e.g. 2048, accounts for some 43mS of delay. Add to this the other various processing and buffering delays and typical mic-to-antenna latency is on the order of 70mS or so.
One thing that has helped a great deal was that Warren Pratt ultimately became interested in achieving latency improvements. This may have been motivated by radios such as the IC-7300, which utilize IIR filtering. IIR filters are quite fast, and the latencies achieved in the 7300 are in the sub 30mS range. There might have also been some "squeaky wheels," such as your's truly
. This lead to the implementation of minimum phase FIR filters in the software, which are labeled "Low Latency" filters in the setup screen, as well as some improvements in buffering architecture. Not quite as fast as IIR filters, but they had mathematical advantages for allowing the real-time, highly flexible adjustments we enjoy in our radios. They also do not exhibit very linear phase characteristics, but considering what the ionosphere does to our signals that is essentially unnoticeable.
Using the Low Latency filters setting, at any length (their delay is insensitive to length), one can achieve mic-to-antenna latencies on the order of 30 to 70mS, depending on buffering settings and how much audio processing is being used (leveler, CFC, EQ, etc.). This was such a great improvement over the 70 to 150mS that Apache Labs "old timers" were used to that many folks took to calling it "real time". Of course it is no such thing, as your own experiments showed. But it is still quite good for an SDR, particularly an SDR with highly sophisticated transmit audio processing (unique to PowerSDR mRX, by the way), as all SDRs suffer from the delays inherent in digital filtering (analog filtering is essentially instant).
Given that the MON output is taken at the data stream where it goes to the DAC, it is subject to nearly the entire delay. Note that it is also subject to any predistortion processing from PureSignal. If you can stand the delay, and want to hear what you really sound like, you need to ensure that PureSignal is disabled when using MON.
I have suggested many times that MON should have three modes: MON1, which is pure, unadulterated sidetone with no processing and the lowest possible latency, MON2, which is picked off after all audio processing but before passband filtering and predistortion, and MON3, which is equivalent to how MON currently works and picks off the signal just before the DAC.
As you have already figured out, if you want low latency sidetone you will have to use a mixer/monitor "lash-up", as you put it. Something else to watch out for is receive-to-transmit latency. With buffers all set to as low as they can go, low latency filters, and no audio processing in use (no CFC, etc.), about the best you can do from the time the other station stops transmitting to when your signal actually leaves the antenna is approx. 60mS (30mS receive latency + 30mS transmit latency). Add some audio processing and this can quickly climb to the 100 to 150mS range. That doesn't sound like a lot, but in a multi-way rag-chew it can sometimes make it hard to break in in a timely fashion.
73,
Scott
P.S. see also this thread.
The latency of every openHPSDR architecture radio, from the Hermes (10, 10E, 100), to the Angelia (100D), Orion (200D) and Orion MkII (8000 and 7000), is exactly the same. They use the same software processing in PowerSDR mRX, the same Ethernet communications protocol between the radio and the PC, the same FPGA code (with respect to audio processing), and the exact same CODEC circuitry to support mic and speaker/headphone connections to the radio. None of the radios have any advantage over the other in this respect.
Which article are you referring to? Where can it be found?
With respect to obtaining simple sidetone, there is absolutely no reason that our radios can't achieve acceptably low latency. The CODEC IC used on every board from the Hermes to the Orion MkII has a built-in, zero latency sidetone path. It is simply not utilized by the software/firmware. Similarly, for those using VAC and fully virtualized audio, the simple problem is there is no software in PowerSDR to create a low latency path from the VAC input to the MON circuit and back out the VAC interface. I've suggested it be added, but it is simply not something the developer community is interested in working on, unfortunately.
With respect to mic-to-antenna latency, and antenna-to-speaker latency, the greatest impediment was the IF passband filter implementation in PowerSDR, which was based on simple linear phase FIR filters. Such filters do provide great phase and amplitude linearity, but also exhibit relatively long latencies. In PowerSDR, when using the linear phase FIR filters, the delay through them in milliseconds is defined by filter length divided by 48 (filter length is erroneous labeled as filter size in the setup window, and the factor of 48 comes from the 48KHz audio processing sampling rate used internally by PowerSDR). Even a filter of a relatively minimal length, e.g. 2048, accounts for some 43mS of delay. Add to this the other various processing and buffering delays and typical mic-to-antenna latency is on the order of 70mS or so.
One thing that has helped a great deal was that Warren Pratt ultimately became interested in achieving latency improvements. This may have been motivated by radios such as the IC-7300, which utilize IIR filtering. IIR filters are quite fast, and the latencies achieved in the 7300 are in the sub 30mS range. There might have also been some "squeaky wheels," such as your's truly
. This lead to the implementation of minimum phase FIR filters in the software, which are labeled "Low Latency" filters in the setup screen, as well as some improvements in buffering architecture. Not quite as fast as IIR filters, but they had mathematical advantages for allowing the real-time, highly flexible adjustments we enjoy in our radios. They also do not exhibit very linear phase characteristics, but considering what the ionosphere does to our signals that is essentially unnoticeable.Using the Low Latency filters setting, at any length (their delay is insensitive to length), one can achieve mic-to-antenna latencies on the order of 30 to 70mS, depending on buffering settings and how much audio processing is being used (leveler, CFC, EQ, etc.). This was such a great improvement over the 70 to 150mS that Apache Labs "old timers" were used to that many folks took to calling it "real time". Of course it is no such thing, as your own experiments showed. But it is still quite good for an SDR, particularly an SDR with highly sophisticated transmit audio processing (unique to PowerSDR mRX, by the way), as all SDRs suffer from the delays inherent in digital filtering (analog filtering is essentially instant).
Given that the MON output is taken at the data stream where it goes to the DAC, it is subject to nearly the entire delay. Note that it is also subject to any predistortion processing from PureSignal. If you can stand the delay, and want to hear what you really sound like, you need to ensure that PureSignal is disabled when using MON.
I have suggested many times that MON should have three modes: MON1, which is pure, unadulterated sidetone with no processing and the lowest possible latency, MON2, which is picked off after all audio processing but before passband filtering and predistortion, and MON3, which is equivalent to how MON currently works and picks off the signal just before the DAC.
As you have already figured out, if you want low latency sidetone you will have to use a mixer/monitor "lash-up", as you put it. Something else to watch out for is receive-to-transmit latency. With buffers all set to as low as they can go, low latency filters, and no audio processing in use (no CFC, etc.), about the best you can do from the time the other station stops transmitting to when your signal actually leaves the antenna is approx. 60mS (30mS receive latency + 30mS transmit latency). Add some audio processing and this can quickly climb to the 100 to 150mS range. That doesn't sound like a lot, but in a multi-way rag-chew it can sometimes make it hard to break in in a timely fashion.
73,
Scott
P.S. see also this thread.
Re: Headset monitor and mics
Thank you Scott for the info. I am not concerned with RX to TX Latency - 100ms is not too bad for my operation. Hooking up "my lashup" is no big deal. I have had no problems with RF floating around the shack. Hopefully with the mixer, RF does not rear its ugly head! Interesting that the hardware for zero monitor latency is in the blue box. Maybe someday we will be able to get rid of the box with a software update. 73, Bill, WA2DVU
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
I have only just got my ANAN-100D and having previously used an ANAN-10 at a radio club I ended up using a XENYX 802 to route and monitor audio directly. However I never found this to be particularly satisfactory because I like to hear any dynamic effects that I may have in the signal path, All my operating is DXing or weak signal VHF contests and as a result I deliberately compress and frequency limit the TX audio. Scott would describe it as awful
On 2m in particular I have a very noisy blower and need downward expansion to keep background noise down to an acceptable level. It is important that you can hear this I feel. Otherwise any breathing as the gate opens prematurely really does sound awful!
So it seems to me that I need to monitor the actual processed audio. Would I be correct in assuming that the lowest latency would be available by driving the line input directly from a mixer and listening via VAC with an ASIO driver? I have both a Behringer UMC202DD and a Focusrite Scarlet 2i2 available, the Behringer achieves around 9.6ms round trip latency with my (soon to be improved) system. I have no concept at this stage just how much latency the audio processing will add. The convenience of the USB version of the Xenyx 802 is appealing but I expect the latency to be too high.
I am also dismayed to find that I can only have one ASIO based VAC running.
Scott the link to your VAC article appears to be broken.
I mean this one.
http://wu2o.dyndns.org/wu2o_vac_tutorial_2.html
Regards
Conrad PA5Y
On 2m in particular I have a very noisy blower and need downward expansion to keep background noise down to an acceptable level. It is important that you can hear this I feel. Otherwise any breathing as the gate opens prematurely really does sound awful!
So it seems to me that I need to monitor the actual processed audio. Would I be correct in assuming that the lowest latency would be available by driving the line input directly from a mixer and listening via VAC with an ASIO driver? I have both a Behringer UMC202DD and a Focusrite Scarlet 2i2 available, the Behringer achieves around 9.6ms round trip latency with my (soon to be improved) system. I have no concept at this stage just how much latency the audio processing will add. The convenience of the USB version of the Xenyx 802 is appealing but I expect the latency to be too high.
I am also dismayed to find that I can only have one ASIO based VAC running.
Scott the link to your VAC article appears to be broken.
I mean this one.
http://wu2o.dyndns.org/wu2o_vac_tutorial_2.html
Regards
Conrad PA5Y
-
Tony EI7BMB
- Posts: 652
- Joined: Sun Apr 09, 2017 2:31 pm
- Location: Dublin
- Contact:
Re: Headset monitor and mics
This works Conrad http://wu2o.dyndns.org/wu2o_vac_tutorial_2.html
Re: Headset monitor and mics
The link is working for me.
More to follow on the other questions later.
73,
Scott
More to follow on the other questions later.
73,
Scott
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
Perhaps its just blocked at work, it certainly works fine at home. Too late now but I will read it tomorrow.
Regards
Conrad
Regards
Conrad
Re: Headset monitor and mics
Conrad,
Sorry for the delay in answering, I was not at home yesterday.
73,
Scott
Sorry for the delay in answering, I was not at home yesterday.
So many great strides have been made in the available audio processing features of PowerSDR. It is now second only to external rack processing or full-on digital audio workstation software. Unfortunately, this does not include the gate/expander. Perhaps someday there will be a gate that has adjustable attack/hold/release times. The expansion ratio is adjustable, that is the gate "percentage" setting. Put that at 100% and it is a pure gate. I've found that 90% works best for me, although I don't actually use the gate, I still perform my noise gating in external DAW software. However, I have moved all of my other audio processing into PowerSDR. If and when the gate in PowerSDR gets more sophisticated, I feel confident I can abandon the DAW entirely at that time.Conrad_PA5Y wrote:...On 2m in particular I have a very noisy blower and need downward expansion to keep background noise down to an acceptable level. It is important that you can hear this I feel. Otherwise any breathing as the gate opens prematurely really does sound awful!
Actually, no. The lowest latency is obtained using a high quality, zero latency audio interface with ASIO support for both transmit and receive. Doing this effectively shortens the audio paths, which are otherwise quite lengthy and torturous (refer to this thread). However, care must be taken to optimize the ASIO driver and buffer settings, and of course the VAC settings, to obtain the lowest possible latency. With a UMC202HD audio interface I could normally do about 10mS better than the "standard" audio path, and although I haven't measured it, I know I am doing even better with my near-zero latency Presonus Studio interface. Bryan, W4WMT, gets some really outstanding performance out of his professional PCIE digital audio card, but that thing costs a mint!Would I be correct in assuming that the lowest latency would be available by driving the line input directly from a mixer and listening via VAC with an ASIO driver?
Experience has shown that the Behringer is a superior performer compared to the Focusrite. It has a faster and more stable driver that is easier to adjust.I have both a Behringer UMC202DD and a Focusrite Scarlet 2i2 available, the Behringer achieves around 9.6ms round trip latency with my (soon to be improved) system.
This is where you are going to become disappointed in the latency of the MON function. First, the total latency of the leveler, EQ, CFC compressors and post-EQ create is substantial, measured in many ten's of milliseconds. Then add to that about another 30mS of latency through the low latency transmit filter. The result, even with the most optimized VAC/ASIO setup, is not commensurate with real-time monitoring. This is why you are much better off creating a WAV file recording of your unprocessed audio coming in from the microphone/sound interface (radio or VAC) and then playing that into PowerSDR as a loop using the built-in facilities available via the Wave menu when making adjustments. Rob, W1AEX shows how he does that in his excellent Youtube videos-- see this thread.I have no concept at this stage just how much latency the audio processing will add.
Someday we may see a new VAC output that carries the same audio stream that goes to the radio CODEC. Preliminary work has been done on this and perhaps it will get into a future version of PowerSDR.I am also dismayed to find that I can only have one ASIO based VAC running.
73,
Scott
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
Scott thank you.
Its very late now because I have been on EME, however I will make some comments tomorrow. It seems like I will be buying a small mixer and maybe running a gate as a VST plug in. I have some good ones. Great idea with the loop, now why didn't I think of that!
I suspect that Bryan, W4WMT is using an RME Hammerfall then. I have an audio engineering background so I know what is out there.
More to follow.
73
Conrad PA5Y
Its very late now because I have been on EME, however I will make some comments tomorrow. It seems like I will be buying a small mixer and maybe running a gate as a VST plug in. I have some good ones. Great idea with the loop, now why didn't I think of that!
I suspect that Bryan, W4WMT is using an RME Hammerfall then. I have an audio engineering background so I know what is out there.
More to follow.
73
Conrad PA5Y
Re: Headset monitor and mics
I don't remember the make, but I believe that Bryan is using a multi-channel rack mic pre-amp with AES outputs and is feeding that into an AES IO card. He is also using a Bodnar GPSDO with dual outputs such that one output is a 48KHz world clock to the audio equipment and the other is 10MHz to the radio. Since they are phase locked he has zero under/overruns in the VAC buffers. Not your average setup! 
I will say that the Presonus Studio 192 Mobile I have is quite fast. The only other USB 3 interface I can think of at any sort of reasonable price is the Zoom UAC-2, but I don't know of anybody who has tried it yet. The low price and reasonably good performance of the Behringer UMC202HD is hard to beat for best value.
If you haven't already, I recommend you peruse the various "stickied" audio threads in the PowerSDR sub-forum.
73!
Scott
I will say that the Presonus Studio 192 Mobile I have is quite fast. The only other USB 3 interface I can think of at any sort of reasonable price is the Zoom UAC-2, but I don't know of anybody who has tried it yet. The low price and reasonably good performance of the Behringer UMC202HD is hard to beat for best value.
If you haven't already, I recommend you peruse the various "stickied" audio threads in the PowerSDR sub-forum.
73!
Scott
-
Tony EI7BMB
- Posts: 652
- Joined: Sun Apr 09, 2017 2:31 pm
- Location: Dublin
- Contact:
Re: Headset monitor and mics
This is not a bad price for USB 3 Conrad https://www.waltons.ie/home/products/vi ... interface/
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
The UAC-2 on paper looks very good but the drivers can make or break a product so I would be reluctant to be the first to buy one. The price of the of the Presonus Studio 192 Mobile is way too high for me, I need faster PC before I start splashing out on high end sound cards. Anyway hopefully over the weekend I will get chance to experiment a little.
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
I played it safe(ish) and bought a Behringer UMC404HD,
I will use a virtual mixer and therefore it has enough ins and outs to route my audio from various other radios. The direct monitoring seems a little more versatile than the UM202HD with the addition of a 'mix' control which allows simultaneous monitoring of the playback and direct audio, the ratio can be varied with a pot. One thing that I was not able to find out is how the 4 channels are presented in windows, hopefully as a pair of stereo channels but that is by no means guaranteed. I find that trawling the forums for information is not that productive as you get contradictory information. There are a few you tube videos to watch so maybe that will make things a little more clear.
I should be able to use ASIO on VAC 1 and a none ASIO output on VAC 2 to achieve simultaneous routing of RX1 to WSJT A and and RX2 WSJT B for the H and V polarization respectively, latency is not much of an issue for that particular application. Truthfully I do not know if it will work as expected but I paid under 100 Euros so took a chance.
It will be here next week.
I think that I will also buy Reaper, it seems to have a very versatile mixer and for $60 it is a bargain. Besides I fancy using it for its intended purpose, if I ever find the time.
Then I start with CW, I don't care for break in of any type due to relatively slow TX/RX relays but I do expect this to be 'interesting' as well.
73
Conrad PA5Y
I will use a virtual mixer and therefore it has enough ins and outs to route my audio from various other radios. The direct monitoring seems a little more versatile than the UM202HD with the addition of a 'mix' control which allows simultaneous monitoring of the playback and direct audio, the ratio can be varied with a pot. One thing that I was not able to find out is how the 4 channels are presented in windows, hopefully as a pair of stereo channels but that is by no means guaranteed. I find that trawling the forums for information is not that productive as you get contradictory information. There are a few you tube videos to watch so maybe that will make things a little more clear.
I should be able to use ASIO on VAC 1 and a none ASIO output on VAC 2 to achieve simultaneous routing of RX1 to WSJT A and and RX2 WSJT B for the H and V polarization respectively, latency is not much of an issue for that particular application. Truthfully I do not know if it will work as expected but I paid under 100 Euros so took a chance.
It will be here next week.
I think that I will also buy Reaper, it seems to have a very versatile mixer and for $60 it is a bargain. Besides I fancy using it for its intended purpose, if I ever find the time.
Then I start with CW, I don't care for break in of any type due to relatively slow TX/RX relays but I do expect this to be 'interesting' as well.
73
Conrad PA5Y
Re: Headset monitor and mics
Conrad,
I don't think you are going to be able to do what you want if you use two different drivers on VAC1 and VAC2. The performance differences between the various drivers cause ASIO output to appear many milliseconds before WDM or MME output. The delay is clearly audible. Hence you will likely be better off if you use WDM or MME for both VAC1 and VAC2, assuming you need the audio output from RX1 and RX2 to be synchronous.
And, because VMB does not provide more than two virtual channel strips, that might also pose a challenge. You may actually be better off using a number of Muzychenko VAC cables. You'll have to figure that out.
Personally, I'd like to see an option for VAC1 to carry VAC2 data, in a fully synchronous fashion, on a third and fourth audio channel. That would be fully supported by VMB, as it can handle 8 channels per virtual channel strip (normally for handling Dolby 7.1 audio, but, hey, if it works...)
73,
Scott
I don't think you are going to be able to do what you want if you use two different drivers on VAC1 and VAC2. The performance differences between the various drivers cause ASIO output to appear many milliseconds before WDM or MME output. The delay is clearly audible. Hence you will likely be better off if you use WDM or MME for both VAC1 and VAC2, assuming you need the audio output from RX1 and RX2 to be synchronous.
And, because VMB does not provide more than two virtual channel strips, that might also pose a challenge. You may actually be better off using a number of Muzychenko VAC cables. You'll have to figure that out.
Personally, I'd like to see an option for VAC1 to carry VAC2 data, in a fully synchronous fashion, on a third and fourth audio channel. That would be fully supported by VMB, as it can handle 8 channels per virtual channel strip (normally for handling Dolby 7.1 audio, but, hey, if it works...)
73,
Scott
-
Conrad_PA5Y
- Posts: 101
- Joined: Fri Jan 19, 2018 8:11 pm
Re: Headset monitor and mics
Hello Scott. The latency difference between VAC1 and VAC2 does not matter for fixed H and V channel WSJT EME decoding. As long as the worst case is delay less than 1 second or so. More than this and weak decodes may fall outside of permitted EME delay parameters, especially with new stations who often do not understand the importance of an accurate PC clock. The decoders operate independently of each other and do not require that the streams are coherent. There is no need to listen to the audio and so this will work. I have done something similar previously with audio from 2 transceivers and 2 sound-cards.
On the other hand the ability to stream coherent IQ data from RX1 and RX2 would be a MAJOR plus for use with adaptive RX applications, I currently use an Afedri AFE822x 2 channel SDR with a pair of 144/28 transverters with a common LO and Linrad/MAP65. This is coherent and fully adaptive but it would be much better to use the transverters >ANAN-100D > MAP65 or ANAN-100D> LINRAD > MAP65 as a coherent RX system. I knew that this was not possible and that it is unlikely to happen any time soon so I am not disappointed. It's a real shame because the hardware can support coherent operation.
Regards
Conrad
On the other hand the ability to stream coherent IQ data from RX1 and RX2 would be a MAJOR plus for use with adaptive RX applications, I currently use an Afedri AFE822x 2 channel SDR with a pair of 144/28 transverters with a common LO and Linrad/MAP65. This is coherent and fully adaptive but it would be much better to use the transverters >ANAN-100D > MAP65 or ANAN-100D> LINRAD > MAP65 as a coherent RX system. I knew that this was not possible and that it is unlikely to happen any time soon so I am not disappointed. It's a real shame because the hardware can support coherent operation.
Regards
Conrad