Audio timing walkabout [FT8 decoder problems solved with tighter limits on audio buffering]
I've dumped all the auto-run WSPR & am trying to use the Kiwi for monitoring FT8 on another computer until I have time to mess with the RPi.
It works fine for a bit, but after a while (sometimes a few minutes, sometimes much longer) the presented audio shifts in time too far for JTDX (like WSJT-X) to work with. If I then select the bookmark in my browser again for the frequency I'm monitoring, the presented audio jumps back to around the 1-2 sec delay.
Here it can be seen - JQ1UGE's CQs started to decode after 04:31:45.
![](http://forum.kiwisdr.com/uploads/editor/ku/czd9mzi9z5dz.png)
This on a Lenovo X220 i7, XP SP3 & FF 52.9.0esr.
Any suggestions?
73, VR2BG.
It works fine for a bit, but after a while (sometimes a few minutes, sometimes much longer) the presented audio shifts in time too far for JTDX (like WSJT-X) to work with. If I then select the bookmark in my browser again for the frequency I'm monitoring, the presented audio jumps back to around the 1-2 sec delay.
Here it can be seen - JQ1UGE's CQs started to decode after 04:31:45.
![](http://forum.kiwisdr.com/uploads/editor/ku/czd9mzi9z5dz.png)
This on a Lenovo X220 i7, XP SP3 & FF 52.9.0esr.
Any suggestions?
73, VR2BG.
Comments
I've also seen a few instances where re-selecting the bookmark for what the Kiwi was tuned to did NOT result in the additional delay going away. Re-selecting the bookmark a second or even once for a third time, would. Everything arrives around a second earlier when the Kiwi decides to cooperate.
73, VR2BG.
73, VR2BG.
Ron
KA7U
The other day I switched from VB-Audio to VirtualAudioCable to get the audio into JTDX (as with VAC I can have two instances of JTDX on the same "cable", so I might catch a bit of what JT9/JT65 activity is still out there) & it seemed the problem went away as it kept working for a number of hours - but come morning, I woke up to find the audio was again an additional second later.
I have used both VB-Audio & VAC with multiple instances of JTDX (and sometimes also WSJT-X) on that computer 24/7 back in KH6 with the other SDR, and never seen this creeping delay - so perhaps what happened after switching to VAC was simply a coincidence... when I first started monitoring FT8 on the Kiwi, it did take quite some time (better part of a day?) before the lag increased & I noticed it wasn't copying anymore. The problem seems to happen when it feels like it. Compared to KH6, the computer is loafing now as when I'm there it's my only machine so is chock-a-block doing all sorts of other stuff.
Grrrrrrr.
73, VR2BG.
The Kiwi produces a delay in the audio stream because it has some buffering. Buffering is required because it is the only defense against latency/interruption issues in the network, particularly when the audio is being delivered by the Internet over long distances with lots of potential points of interruption. So you are already being disadvantaged by the time delay of this buffering to begin with. Any additional cumulative delay by other software behaving badly (e.g. sample rate compensation by the VAC) may push the total timing over the FT8 limit.
One thing you could try is reducing the Kiwi buffer size to reduce the fixed delay. The penalty for doing this is that you will have much less immunity to short-term network interruptions. That means it's important to make sure there are no highly variable latency devices in the path between the Kiwi and computer running the browser, like a WiFi router or a cheap Ethernet switch that might behave badly with heavy traffic on the other ports.
Add "abuf=n.nn" to the URL where n.nn is a number in seconds of the minimum audio buffer size. Start with 0.5 and experiment with a range from 0.3 to 0.8
It would also be interesting to know on the control panel "Stats" tab what the value of the Audio "Qlen" (queue length) is when you are having problems versus what the value is when starting (this value will vary when the abuf= value is changed)
73 SV1DH
Whatever it is, yes, all combined the delays can put the audio too late for decoding referenced to real time. W9MDB has a utility to let you offset the clock in order to copy those not synced & too far off, but it seems it doesn't run on XP. Before I try shortening the buffer, I'll watch Qlen. The Kiwi is on a dead 15m now, so dunno if they audio has indeed slipped... Qlen started at a steady 5 & now after about 15 minutes or so is 7, with the occasional 6 or 8.
SV1DH: Thanks for confirming you observe the same behavior. Which OS/browser/"cable" are you using?
73, VR2BG.
You can also specify the parameter "audio" (or "audio=1") and every time you change frequency in the browser a message in console window will show you the measured delay between the change in audio on the Kiwi and the resulting audio change detected at the browser. Effectively measuring the audio delay of the entire path (Kiwi + network + browser/javascript). You'll note there is a lot of jitter in this number because there are so many variables involved.
73 SV1DH
73, VR2BG.
The OS/browser determines if a 48 or 44.1 kHz audio output rate is required and tells me what I must provide. I don't get a choice and I am required to do sample rate conversion in the Javascript code. I've seen cases where some OS/browser combinations request 22.05 kHz. So I have to be able to support sub-multiple rates as well. And we haven't even talked about decompression or the additional filtering that has to be done.
With 1.273, finding abuf=0.7,1.1 avoids under runs & places all but those with really late clocks within the decoding window. It's great being able to turn it loose & not have to keep checking on it all day - tnx!
73, VR2BG.
I've been able to drop the latency from ~1.5 seconds to ~1 second by using abuf=0.3,0.5. Just wondering if it's possible to drop this even further...
I ran into this problem using Ubuntu 20.04 making a pulseaudio virtual audio sink a couple days ago. It was worse than when I used the actual playing audio channel. It usually didn't work for long at all. I'll have to try this solution, and see if it helps.
Thanks for the pointer!
Rob
KL7NA
I stubled across a handy solution to compensate buffer delay with wsjt-x.
Under linux you can run a command with "faketime", so it runs on a time offset. For example:
But obviously one doesn't want to transmit like that.
I use BktTimeSync (free) with Windows, and set an offset of -1 second, which seems to be good for use with most KiWi's.
https://www.maniaradio.it/en/bkttimesync.html
Regards,
Martin