locked 13 Second Lag Between Visual and Audible Alert #FT8


Glen Jenkins WB4KTF
 

Hi folks
I get a 12-13 second lag between the time that I see the red background alert to the time that the audio alert occurs.  Any idea how I shorten this lag?
--
Glen, WB4KTF, Austin, TX


HamApps Support (VK3AMA)
 

On 23/07/2021 10:07 am, Glen Jenkins WB4KTF wrote:
I get a 12-13 second lag between the time that I see the red background alert to the time that the audio alert occurs.  Any idea how I shorten this lag?
--
Glen, WB4KTF, Austin, TX
There is no lag to shorten. Sounds are queued to play within milliseconds of a decode being processed.

What version of JTAlert?
What version of WSJT-X?
What version of Windows?

Is this excessive lag a new behavior or has JTAlert always doe this for you?

de Laurie VK3AMA




Paul W5PF
 

Laurie,

I have noticed that when I am not connected to the internet the audible alerts occur after the first decode cycle of the next period. That is about 13 seconds into the 15 sec cycle. All works fine when I am connected. Not sure if this has any bearing on Glen's problem, just  a data point.

73, Paul W5PF

On 7/23/2021 2:48 AM, HamApps Support (VK3AMA) wrote:
On 23/07/2021 10:07 am, Glen Jenkins WB4KTF wrote:
I get a 12-13 second lag between the time that I see the red background alert to the time that the audio alert occurs.  Any idea how I shorten this lag?
--
Glen, WB4KTF, Austin, TX
There is no lag to shorten. Sounds are queued to play within milliseconds of a decode being processed.

What version of JTAlert?
What version of WSJT-X?
What version of Windows?

Is this excessive lag a new behavior or has JTAlert always doe this for you?

de Laurie VK3AMA




Glen Jenkins WB4KTF
 

Laurie,
I use these Versions:
JTAlert Version: 2.50.4
WSJT-X Version: 2.4.0
Windows Version:  Version  10.0.19042 Build 19042
This time lag started during JTAlert Version 2.50.2 or .3, I do not remember, but it was in the past month.
Using a Microsoft Surface Pro 3, with Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 2501 Mhz, 2 Core(s), 4 Logical Processor(s)

--
Glen, WB4KTF, Austin, TX


Bob Willey K3RLW
 

Sounds like a possible Computer performance issue.
Either too many things running in the background,
or else and older/slower computer that cannot keep up.
I have an older computer I sometimes use, and it exhibits a similar issue, lag time, even 10-15 seconds before Call Decodes windows is populated.  Out of sync


photo
Bob Willey
K3RLW

(410) 251-8960 | K3RLW@...

http://qrz.com/db/K3RLW

5161 Ocean Gateway, Trappe Maryland 21673-2023 USA


On Thu, Jul 22, 2021 at 8:08 PM Glen Jenkins WB4KTF <wb4ktf@...> wrote:
Hi folks
I get a 12-13 second lag between the time that I see the red background alert to the time that the audio alert occurs.  Any idea how I shorten this lag?
--
Glen, WB4KTF, Austin, TX


--
Bob Willey - K3RLW


Ron W3RJW
 

Open Task Manager and look at the 'performance' tab, CPU. Memory etc. Is any thing pegged?  I likewise have only seen this when I had a computer that was severely strained for resources.
--
73
Ron, W3RJW

FTdx-5000, Timewave Navigator, WSJT-x 2.5.0, rc3 Improved, JTAlert 2.50.2, HRD Deluxe v6.7.0.357
FTdx-3000, SignaLink USB


Ron / W4MMP
 

Hi Glen,

This sounds similar if not the same as I problem I experienced when our internet access was coming and going.   If you have JTAlert accessing anything via the internet (Callbook lookups, HamQTH, QRZ,etc or accessing any of the online logbooks (HDRLog, HamQTH, eQSL or ClubLog), and network access is not available for any reason,  JTAlert will hang attempting access until it times out. 

73,
Ron / W4MMP
On 7/22/2021 20:07, Glen Jenkins WB4KTF wrote:

Hi folks
I get a 12-13 second lag between the time that I see the red background alert to the time that the audio alert occurs.  Any idea how I shorten this lag?
--
Glen, WB4KTF, Austin, TX


HamApps Support (VK3AMA)
 

On 24/07/2021 2:28 am, Glen Jenkins WB4KTF wrote:
Using a Microsoft Surface Pro 3, with Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 2501 Mhz, 2 Core(s), 4 Logical Processor(s)

--
Glen, WB4KTF, Austin, TX
How much memory do you have in the Surface Pro?

How late into the new FT8 period is WSJT-X still producing decodes from the previous period, how many seconds approxiamtely?

What is the CPU usage (check with taskmanager) for WSJT-X while it is actively processing the decodes at the end of an Rx period?

What decoding depth do you have set in WSJT-X? Fast, Normal or Deep, is AP enabled?

Do you see the same lag if on a non-busy band?


de Laurie VK3AMA


Glen Jenkins WB4KTF
 

Hello Laurie,
8GB Installed Memory.
The CALLSIGNS - All Decodes Window follows WSJT-X and populates at the 12th second of the 15 second receive cycle.  The audio Alert happens at the 13th of 15 second Transmit Cycle (the next cycle). 
From Task Manager:  CPU Usage is: 13 to 15% nominal, Peaks to 70 to 90% every 30 seconds, but never to 100%.  These Peaks are short at about 1 second or less long.
Decode Depth is DEEP.  I then changed DEPTH to Normal and Fast, the Audio Alert still occurs at the 11th of 15th second cycle (during transmit cycle).  In other words I do not have any difference with any of the 3 Depth settings.
Memory is stationary at 58% usage of the 8GB of installed memory.
As for a quiet band, I tried 17m FT4 at night.  6 stations decoding in WSJT-x. The Callsigns All Decode window populates fast, as normally it should.  The Audio Alert now occurs two cycles later in about the 3rd of 7.5 seconds.  Seems to still be the same overall delay/lag as with FT8.  
Hope that this helps with understanding this issue.
I can of course live with this lag, it is just a little annoying :-)).
--
Glen, WB4KTF, Austin, TX


Jim Cooper
 

On 23 Jul 2021 at 19:54, Glen Jenkins WB4KTF wrote:

I can of course live with this lag, it is just a little annoying
just an idea, but get yourself a $5 usb sound dongle
and plug it into a usb port and assign that to the sound
alerts ... see if it makes a difference (idea being this
will remove any anomolies there might be with whatever
sound assignment you have now).

Since most of us are not experiencing such a delay,
the likely problem is local to your hardware.

w2jc


HamApps Support (VK3AMA)
 

On 24/07/2021 12:54 pm, Glen Jenkins WB4KTF wrote:
8GB Installed Memory.
The CALLSIGNS - All Decodes Window follows WSJT-X and populates at the 12th second of the 15 second receive cycle.  The audio Alert happens at the 13th of 15 second Transmit Cycle (the next cycle). 
From Task Manager:  CPU Usage is: 13 to 15% nominal, Peaks to 70 to 90% every 30 seconds, but never to 100%.  These Peaks are short at about 1 second or less long.
Decode Depth is DEEP.  I then changed DEPTH to Normal and Fast, the Audio Alert still occurs at the 11th of 15th second cycle (during transmit cycle).  In other words I do not have any difference with any of the 3 Depth settings.
Memory is stationary at 58% usage of the 8GB of installed memory.
As for a quiet band, I tried 17m FT4 at night.  6 stations decoding in WSJT-x. The Callsigns All Decode window populates fast, as normally it should.  The Audio Alert now occurs two cycles later in about the 3rd of 7.5 seconds.  Seems to still be the same overall delay/lag as with FT8.  
Hope that this helps with understanding this issue.
I can of course live with this lag, it is just a little annoying :-)).
--
Glen, WB4KTF, Austin, TX

Glen,

Question: What happens when you restart JTAlert, does the sound delay still occur for the very first batch of decodes after the restart?
Question: Are the JTAlert callsigns clearing at the end of a period or are they hanging around resulting in duplicate callsign displays?

Regarding living with the Lag, you should not have to. Something is not right and the source needs to be identified.

de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 24/07/2021 4:31 pm, HamApps Support (VK3AMA) via groups.io wrote:
I tried 17m FT4 at night.  6 stations decoding in WSJT-x. The Callsigns All Decode window populates fast, as normally it should.  The Audio Alert now occurs two cycles later in about the 3rd of 7.5 seconds

That's the clue! You have a sound play limit set, likely 15 seconds, which when set will limit the play frequency of individual sounds to once every 15 seconds. or whatever limit is set. What you're hearing is the current period announcements, but are misinterpreting them as the previous period.



Do you have a Play Limit set?

de Laurie VK3AMA


Glen Jenkins WB4KTF
 

Hello Laurie,
The Sound Play Limit was set at 'NO LIMIT', so that is not the cause.
I'll continue to test various things and report back when I figure more out.
I did try rebooting the Surface and restarting both WSJT-X and JTAlert, no change so far.
The alert sound still starts to play at the 10-11th second of the following cycle after the decode in WXJT-X and Callsigns/All Decodes window is filled.
--
Glen, WB4KTF, Austin, TX


HamApps Support (VK3AMA)
 

On 26/07/2021 12:25 am, Glen Jenkins WB4KTF wrote:
The Sound Play Limit was set at 'NO LIMIT', so that is not the cause.
I'll continue to test various things and report back when I figure more out.
I did try rebooting the Surface and restarting both WSJT-X and JTAlert, no change so far.
The alert sound still starts to play at the 10-11th second of the following cycle after the decode in WXJT-X and Callsigns/All Decodes window is filled.
--
Glen, WB4KTF, Austin, TX

Dagnammit, I was sure that was the cause.

Question: What happens when you restart JTAlert, does the sound delay still occur for the very first batch of decodes after the restart?
Question: Are the JTAlert callsigns clearing at the end of a period or are they hanging around resulting in duplicate callsign displays?
Question: Does using the "Sound -> Test Sound Output" menu produce the same delay?


de Laurie VK3AMA


HamApps Support (VK3AMA)
 

On 26/07/2021 4:33 am, HamApps Support (VK3AMA) via groups.io wrote:
On 26/07/2021 12:25 am, Glen Jenkins WB4KTF wrote:
The Sound Play Limit was set at 'NO LIMIT', so that is not the cause.
I'll continue to test various things and report back when I figure more out.
I did try rebooting the Surface and restarting both WSJT-X and JTAlert, no change so far.
The alert sound still starts to play at the 10-11th second of the following cycle after the decode in WXJT-X and Callsigns/All Decodes window is filled.
--
Glen, WB4KTF, Austin, TX


Glen,

I previously asked but got no answer...
Does using the "Sound -> Test Sound Output" menu produce the same delay?
This question is important. The test function uses the same code and an identical execution path though JTAlert to the Manager process (that plays the audio) as that used by Sound events when an Alert is triggered. If there is a delay it should also show up in that test.

Using your config in my tests produced no sound play delays. All looks normal in your session files except there is only a very small number of sound play events. That is likely because you have CQ only filtering enabled and some of the enabled Alerts don't have a sound file set.
Does turning off the "CQ Only" filter fixed the audio lag?

I personally can't fault your config. I left thinking that due to the low number of sound play events that you may be misinterpreting the sounds that do play as being from an earlier period.

I also note a very large number of Internet timeout errors when spots are being uploaded to HamSpots and when checking the online for messages status of decoded callsigns. Do you have a flaky or very slow Internet connection? Not that it should matter as the sound play is on a different, independent, code thread from that used for uploading spots. A timeout on one should not affect the other, but I could be wrong, there may be an unidentified defect in the code. Try turning off spotting to HamSpots and turning of Messaging. Turn off Messaging via the main JTAlert window Settings.

   

de Laurie VK3AMA