Question on Audio Delay when using DAX

Jeff_W4DD

If I send audio into the computer sound card (Mic In) and pass it to the audio out of the sound card and then into the back of the 6600 using a cable, the audio delay is unperceivable. If I use DAX to make the audio transfer from the sound card to SmartSDR rather than a cable, there seems to be hundreds of ms of audio delay. I expected once into the PC sound card the DAX transfer to have less delay. My question is why is this the case and what Hardware or software component adds this delay. (LAN delay is only 1-2 ms and the PC is a 4 core with low CPU and graphics utilization). Thanks for any info.

Mike-VA3MW

Great question and I don't have a solid answer.

I think that in your test, Windows just routes it directly back out, like for a system monitor type solution.

However, in any other path, it has to run through all Windows 5 subsystems which I discussed here. https://community.flexradio.com/discussion/8023291/rx-audio-latency

Mike

Jeff_W4DD

Thanks for the information Mike. 

I thought it would be worthwhile to quantify what the latency is.  Since WWV has a one second time tick, that makes a good pulse to kick off the measurement process.  I measured the Rx delay, but suspect the Tx delay would be similar as transmit likely goes through similar processes.  I listed my setup below in case others wish to duplicate it and do further testing.

Test Setup:

I used a Tektronix dual channel oscilloscope to do the measurement. The built-in time base should be accurate enough for measuring the audio delay to within 10ms.

Channel 1 of the oscilloscope gets an audio signal from an analog transceiver, in this case an old Kenwood TS-690 tuned to WWV at 10MHz.  I triggered the scope off of this channel so it triggers every one second when it sees the WWV tick tone.  WWV cycles through various tic tones every 60 seconds.  For measurement purposes, it is best to use the plain tic tone that does not have other tones superimposed on it.  I assume the old analog receiver has a very short delay, perhaps under a millisecond (ms).  I found it useful to feed the audio signal to both the scope and an external speaker using a Y cable.  Pick a frequency and time when WWV has a solid signal.

Channel 2 of the oscilloscope gets the Flex audio signal, first from the back of the Flex 6600, then in the second test from the Audio output jack (speaker) on the desktop PC.  I found it useful to feed the audio signal to both the scope and a set of headphones using a Y cable.  Depending on how much audio level your PC audio card produces, you may or may not be able to add in the headphones as that tends to reduce the audio level.

Results:

Results – Flex Audio Jack: I measured 160ms of audio delay compared to the analog receiver.  I'm not sure where this delay originates in the Flex, from the ADC, FPGA, or the baseband processor. My guess is the baseband processor, which does the demodulation function.

Results – Desktop PC Speaker Audio Output Jack: I measured 630ms of audio delay compared to the analog receiver, an increase of 470ms.  My Dell PC has a 3.3GHz Intel i5 CPU which runs about 10% CPU utilization and 20% graphics utilization so PC loading would not seem to be the cause.  It uses a built-in sound card identified as a Realtek chipset.  I ran this test on my LAN which has 1-2ms of network delay (RRT).  If you are operating remotely, with say 200ms of round tip delay, you would need to add half of that to come up with the total audio latency you would encounter when remote.

There was mention in an earlier posting of the subsystems of the Windows audio stack.

https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/low-latency-audio

The summary of that stack (below the graphic) indicates “In Windows 10, the latency has been reduced to 1.3ms for all applications”. So it’s not clear as to where the latency is generated in Windows, assuming Microsoft’s summary is correct. If someone has a deep understanding of the Windows Audio Stack (WAS), feel free to enlighten us.

 

Mike-VA3MW

Hi

Your test is well thought out and similar to mine. Excellent job to eliminate many variables.

For test 1 160ms sounds long. Is that with the default Filter settings and what mode. You should see numbers similar to these:

Test 2 is a bit longer than what I measured a year ago and it doesn't matter how fast the PC is. My guess is it is related to a buffer size issue. The bigger buffers take longer to fill but are more reliable. Smaller buffers are faster but drop more packets.

Thanks for reposting that link. I need to go digest it again, but I have yet to seen any Windows 10 application that is that fast.

Jeff_W4DD

Yes, In Settings/Filters they are all set to AUTO.

Another way do the test would be to record L and R channels on a separate pc with a good timestamp. Analog radio to one channel, Flex to the other channel. That way the data could be saved.

Mike-VA3MW

I agree about your other test, but Windows is part of the problem. :) I might use a MAC or a Linux box first.

Jeff_W4DD

I finally found some time to complete Rx Latency measurements. This time I used a software-based oscilloscope (on another PC), but results were almost identical to the analog oscilloscope.

I used WWV timing pulses and an analog transceiver to provide the Time=0 reference. The Flex 6600 filters were adjusted in the Settings Menu / Filter Option, "Voice Settings". I used USB, 2.7KHz BW. Audio from the back of the 6600, headset output:

Voice Filter Level 4 (Sharpest Filter) = 166ms

Voice Filter Level 3 (default) = 166ms

Voice Filter Level 2 = 71ms

Voice Filter Level 1 (Lowest Latency) = 54ms

The values DID change based on whether Level 1, 2, or 3 were selected but not when Level 4 was selected.

For CW Settings, 400HZ BW: latencies were the same as the Voice measurements for the four filter levels.

When I enabled "PC Audio" at the top right of the pan adapter screen and pulled the audio off a USB connector on the PC, the audio delay increased to 610ms, an increase of 444ms over the audio at the back of the radio. This occurred across all Filter Levels so something with the fact the Flex is sending the audio stream to the PC (over the LAN Connection) where the PC processes it. (The LAN is GigE with PC to 6600 ping times of 1ms so the additional latency is not in the LAN).

Improving Rx latency:

• I noticed an interesting change that seemed to improve the Windows latency. If I adjusted the properties of my sound card from DVD Quality (16 bit, 48KHz) to CD Quality (16 bit, 44.1KHz), the latency dropped to 430ms, an improvement of 180ms. For ham use, CD quality is more than adequate. Each sound card is different and there may be lower settings available on other sound cards (or a different driver) and it may be possible to improve the latency further. We don't need anything over 6KHz. Others may want to try this if operating remote (aka, audio not off of the back of the radio).
• After returning after a lunch break, I also notice that the latency dropped to 370ms, but returned to 430ms after I started to work with the PC again. Not year clear why this occurred but perhaps something to do with the priority of sound processing when loads are light.

Jeff_W4DD

I finally found some time to complete Rx Latency measurements. This time I used a software-based oscilloscope (on another PC), but results were almost identical to the analog oscilloscope.

I used WWV timing pulses and an analog transceiver to provide the Time=0 reference. The Flex 6600 filters were adjusted in the Settings Menu / Filter Option, "Voice Settings". I used USB, 2.7KHz BW. Audio from the back of the 6600, headset output:

Voice Filter Level 4 (Sharpest Filter) = 166ms

Voice Filter Level 3 (default) = 166ms

Voice Filter Level 2 = 71ms

Voice Filter Level 1 (Lowest Latency) = 54ms

The values DID change based on whether Level 1, 2, or 3 were selected but not when Level 4 was selected.

For CW Settings, 400HZ BW: latencies were the same as the Voice measurements for the four filter levels.

When I enabled "PC Audio" at the top right of the pan adapter screen and pulled the audio off a USB connector on the PC, the audio delay increased to 610ms, an increase of 444ms over the audio at the back of the radio. This occurred across all Filter Levels so something with the fact the Flex is sending the audio stream to the PC (over the LAN Connection) where the PC processes it. (The LAN is GigE with PC to 6600 ping times of 1ms so the additional latency is not in the LAN).

Improving Rx latency:

• I noticed an interesting change that seemed to improve the Windows latency. If I adjusted the properties of my sound card from DVD Quality (16 bit, 48KHz) to CD Quality (16 bit, 44.1KHz), the latency dropped to 430ms, an improvement of 180ms. For ham use, CD quality is more than adequate. Each sound card is different and there may be lower settings available on other sound cards (or a different driver) and it may be possible to improve the latency further. We don't need anything over 6KHz. Others may want to try this if operating remote (aka, audio not off of the back of the radio).
• After returning after a lunch break, I also notice that the latency dropped to 370ms, but returned to 430ms after I started to work with the PC again. Not year clear why this occurred but perhaps something to do with the priority of sound processing when loads are light.

N2ADV

Sorry to participate in thread necropsy but I was experiencing a similar issue and decided to perform a search of the Community before posting a similar question/issue. I have noticed the same latency issue. I have set the quality to the lowest setting in Windows (still running 10) and it has not improved my RX DT at all. All of my devices are hard wired (not on wifi) using short runs (3 feet or less) to the router.

Any other ideas out there?

Time.is shows my time as spot on (I've used both Meinberg and BKTTimesync just to make sure it wasn't my time sync program). When I look at the DT column, I'm seeing no values below 0.4. With my Elecraft K3 decoding the same signals, I'm showing those same 0.4 DT's as 0.0 and 0.1.

Mike-VA3MW

Your DT is a function of

1. Having the correct time
2. The time it takes for the signal to get from the air to the computer -- DAX adds a bit
3. How long it takes for your computer to actually decode the signal.

I touch on it in this video and show how you can make it worse to the point of failure.

73

https://youtu.be/Pd3e8z-DS0w

N2ADV

FWIW, I don't run SmartSDR on my machine where WSJT-X is running (most of the time, I'm using the Maestro to control the settings on the radio). My CPU total percent used almost never exceeds 30%.

vectorizer

FWIW, I consistently see about a +0.3 DT average using two different Flex 6500 radios on two different powerful-enough-to-edit-video computers with their clocks correct by Meinberg and "confirmed" on time.is. My ICOM IC-7100 and IC-705 is 0.0 to 0.1 on a much less powerful laptop computer. You're not imagining it. If it bugs me enough, I adjust the computer clock with the useful little TimeFudge program.

Mike-VA3MW

The 0.3 DT isn't really a number you need to worry about. FT8 can easily handle up to 2.5 seconds. I did confirm that by discussing it with the author at a FlexRadio Banquet in Dayton.

If you see all the numbers start to increase through 1.0 seconds, then it is time to start to dig and understand what is happening.

JTDX has a great report on the top of the screen that shows the average and another called LAG that shows you how much head room you have.

N2ADV

I worked directly with the WSJTX Dev team on the entire gamut on DT and spent quite a bit of time over Skype with Bill, G4WJS on it. Though 0.3DT does not cause decodes to stop entirely, it does mean that you are beginning to exclude those stations who already have a 0.2 and 0.3 DT so decodes begin to fall off. This impacts the abilitty to decode stations in countries where they do not have reliable internet connections and their ability to sync with GPS is non existant due to the lack of the needed hardware. Everyone loves to just throw out there, "Oh, X DT is not a big deal" but they fail to think about every other station on the air. I will continue to try to find a way to mitigate the delay or the Flex will end up going in favor of a different radio. On another note, 0.3 is a huge liability in FT4 especially for the reason I mention above.

David Decoons, wo2x

@N2ADV Even with seeing on average .3 DT I still see in excess of 50 decodes per cycle on FT8, sometimes up to 60 when the band is hot. Not sure who I am missing?

I edited my response - FT8 uses triple decoding with forward error correction. FT4 uses double decoding per cycle with forward error correction. See below. Since WSJT-X has a TX Delay setting by default between assertion of PTT and beginning of audio and almost all users have it as 1 or 2 seconds, the 0.3 DT should be a non-issue.

From the WSJT-X developer list -

The DT figure is the measured difference between your PC clock and the sync of a decoded signal. A positive DT implies that the signal clock is behind yours. Positive components of the DT are the sender's clock being slow, and propagation delay. Also contributing are latencies including audio buffering and other processing delay which can be at either of both ends of the link and like propagation delay can only increase the DT, net clock difference can contribute a negative or a positive DT component.

Dave wo2x

N2ADV

The world does not revolve around FT8. FT4 is where timing becomes more important.

Ron Koenig

I'm really not sure how this is even a debate. The high latency filters in the Flex have a negative impact on FT4, this is well known and well documented. I too was on the FT4 Alpha team and this was discussed at length. An IC7300 will Smoke a Flex on FT4 in a serious effort, I proved that.

How much does this affect the casual user ? Probably not much... They don't know what they don't know. But I promise with the added .3 DT on FT4 you ARE missing Decodes and you Will have more busted Q's. It's tolerance stacking.

Ron, WV4P

David Decoons, wo2x

So, if the Flex is delayed 0.3 in receiving but the transmitting station's audio is delayed 1 second, how is this an issue? and why can I decode -0.3 stations then?

N2ADV

I am not going to keep trying to justify that this is an issue. The fact remains that it is an issue for my style of operating. If it isn't an issue for you, that's great, gold star for you.

Rumor has it that the next version of SmartSDR and Dax has potential fixes for this - I'd be interested to hear about that.

Ron Koenig

Dave,

It's Tolerance Stacking.

If ALL Stations were 0.0 DT then it would only depend on the stations and propagation.

the .3 is cumulative, it adds to an existing DT offset of the other station. With FT4 anything over .5 starts to have a major impact. When you "Intentionally" add .3 as your baseline you have eliminated stations from decoding that you could if you had a 0.0 baseline.

It's really simple. I suspect that it's the reason Low Latency Digital filters are in the pipeline and that in and of it's self confuses me as to why this sudden, incorrect insistence that the current ~.3 latency is a non issue.

Does this post and the recent video not shoot yourself in the foot when the new version is released ? I think I'd of played this all differently myself. Instead of Denying the well known issue I would have embraced it, maybe hinted that help is on the way and then released the update with a ton of people happy that a problem they didn't even know they had was fixed. Instead, the release will now fix a problem the experts say does not exist... I'm perplexed.

David Decoons, wo2x

@N2ADV, by your logic, I cannot make contact or I should not even see a station if they are less than 0.3 DT. Why did I make contact first call with a station at -0.8?

You are missing the point. WSJT-X has a buffer built in to allow for differences in station's PC time and propagation delay. The buffer is about 2 seconds on FT8 and tighter (1/2 that) on FT4. Which would put it at 1 second. 300 ms is way below that.

I do NOT have issues making FT8/FT4 contacts. And lots of them.

I still don't see your argument if a radio is within the grace period it will encode and decode fine

Mike-VA3MW

Dave, I had to go have a look on 10M FT4. All good points

https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf

This is on a remote 6600 with the filters set to a minimum on the radio for digital operation, which is fine as there is no real requirement to have a sharp filter at this point.

I have no issue decoding from 0.0 all the way to 0.8 on a correctly synchronized system which is good.

Also, notice the LAG is -0.78 sec, which is a good indication of computer resources. Plus numbers are an indication of things not going so well especially if you get over 1.0.

The average of the DT times for the last cycle copied here is 0.26 seconds. As I type this, I can even see some 1.0 DT's.

YMMV

N2ADV

@David Decoons, wo2x

"by your logic, I cannot make contact or I should not even see a station if they are less than 0.3 DT. "

Please point out where I said that?

I'd ask that you please not attibute your misunderstanding of my issue to "my logic" please.

@Ron Koenig has explained it better than I did and I appreciate his response for that.

It appears representatives of Flex are doubling down on denial of this being an issue which I find alarming, especially as I've gone to great lengths in the past to defend Flex in many forums.

I can see this is a dead end, unfortunately.