Page 2 of 2

Re: Headset monitor

Posted: Tue Nov 14, 2017 1:08 pm
by Tony EI7BMB
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.

Re: Headset monitor and mics

Posted: Tue Nov 14, 2017 9:24 pm
by w-u-2-o
It's amazing how much mic you can get for $99, isn't it? :D

Re: Headset monitor and mics

Posted: Wed Nov 15, 2017 12:47 am
by Tony EI7BMB
Sure is Scott

Re: Headset monitor and mics

Posted: Thu Nov 16, 2017 10:11 pm
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.

Bill, WA2DVU
Potato Island, NJ

Re: Headset monitor and mics

Posted: Fri Nov 17, 2017 2:33 am
by w-u-2-o

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.



P.S. see also this thread.

Re: Headset monitor and mics

Posted: Fri Nov 17, 2017 3:47 pm
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