The forum is read-only currently.

v1.446/445/444

From the CHANGE_LOG file. Not a lot new here. Except for days of tedious checking for memory errors (buffer overruns) and memory leaks to rule out a possible cause of the Windows 10 audio problems.

v1.446 March 28, 2021

  WSPR extension:

    By request: Added 6 & 13 MHz ISM bands (UK balloon-mobile operation).

    Can restart autorun decoders via an admin page button instead of server restart.

   

  Windows 10 audio "popping" problem:

    Looked for memory addressing errors and leaks with the Clang address sanitizer.

    A few minor issues fixed but nothing that changes the audio problem.

    This was expected, but also had to be ruled out.


v1.445 March 24, 2021

  SNR measurement:

    Take transverter frequency offset into account.

    Display SNR value(s) on user (top bar) and admin pages (status tab).


  Added SAM PLL loop control to audio tab.

    Has a slow loop setting "DX" that can be used to better track weak stations.


v1.444 March 23, 2021

  Include two most recent SNR values in /status query. This implies all the SNR values

    for public Kiwis will be aggregated in the rx.kiwisdr.com/index.html file

    HTML comments.

   

  TDoA extension:

    Improved help panel contents.

    Added warning against prematurely using too many sampling stations because of

      the large number of computation timeouts we see on the server.


rz3dvpHB9TMCnjc

Comments

  • John,

    Thanks for your continued efforts. I still have the popping on v1.446. I noticed something interesting that might be a clue. If I change the sample rate via windows control panel (mmsys.cpl) I can change the frequency of the pops. At 192k the pops are very fast, pretty much continuous. 44.1k/48k approx 2Hz pop rate. I'm not sure if this is helpful at all. What is the output sample rate from the kiwi application? Is it the same on SAM/CW as it is on AM/SSB?

    Nick

  • That sounds like the Windows system audio rate. The Kiwi javascript code resamples the audio network rate from the Kiwi to match the system audio rate. The Kiwi network rate varies depending if IQ or real data is being sent and if 4:1 compression is being used in real mode (compression is never used in IQ mode).

    A Javascript routine is called as required to fill the Windows audio buffers. If anything along the Kiwi path isn't keeping up you get those "audio underrun" error messages. But if something is wrong keeping Windows audio fed then that is something I can't detect and not my fault. Windows, the browser and Javascript engine have to guarantee realtime requirements to stream the audio without buffering issues. Cranking the Windows system audio rate up to 192 kb will stress that path more. So I take that as more evidence this is a non-Kiwi issue.

  • edited March 29

    As I blathered before SDR Console did hit audio chopping on Windows 10 issues with virtually no systems load, high end PC's. Some users found they could reduce it by running a chrome session in the background loading the system. Simon looked into his code thoroughly but nothing was found (last I was there). That is a windows code base on a windows system running with enough grunt to do fifty+ receive windows. A quick web search will find many reports and "realtek audio popping Win 10" is a great way to lose a hour or four.

    I'm a certified tin foil hatter and have noticed the issue is very similar to running a virtualised system, so perhaps the multiple shims for user monitoring under windows is catching up with it, recently I had a problem with a windows install and was shocked how much of the current (settings) GUI will run apparently fine, completely disconnected from the parameters it is meant to be affecting.

    Run a browser that does work like Firefox and let MS cover it up later ;-).

  • Just upgraded to v1.446 and then set WSPR extension bands for 80, 40, 30 meters. Noted spots overnight. All looked good. Then, this morning, I went to the Extensions and changed the bands to 17, 15 and 10; then clicked on the new button Autorun Restart.

    I then noted the spots on Status after things had run for about an hour. 17,15,10 bands should have very few spots this time of day here, yet it appeared to be tracking the spots on 80, 40 and 30 based on the spot count...?

    So I went to Control, KiwiServer Restart and after it completed, checked status - now all appears to be operating correctly.

  • Had another thought about the WSPR extensions... I think the 'tally' of spots is the cumulative number for an individual receiver so probably my issue is likely not a problem (see my previous post). (I think I was expecting to see the spot count on Status reset to zero after an Autorun Restart.)

    73, Doug

  • No, it's a bug. The spot counter is supposed to be zeroed on restart.

  • Fixed in today's v1.447 release.

  • Works now as expected with v1.447. Thank you!

Sign In or Register to comment.