V1.158 Audio Underruns ? [try browser site-data-clear]

Constantly since this update ? 

Anyone else have this issue and how can I fix it ?


  • I've noticed this on other Kiwi SDR's too since the last update or two and sometimes a refresh or two fixes it but it's most annoying on mine, nothing solves it. 

    i'll try a reboot.
  • jksjks
    edited January 2018
    Nothing audio related has changed in the last few updates. If anything were generally broken then my inbox would be full.

    The only known problem is trouble using kiwisdr.local with recent Window 10 updates. See here: http://forum.kiwisdr.com/discussion/discussion/1023/audio-underruns-when-using-kiwisdr-local-on-windows-10-pro-a-solution

    If you are having issues with both your Kiwi accessed via a local network and Kiwis in general on the Internet that kind of suggests a local network latency issue. Try pinging your router (if possible), your Kiwi Beagle, google.com etc. and see not only the average times but the maximum time to try to gauge if there are periods of long latency.

    Here's an example. A few days ago my local WiFi network was being used to watch a movie from the Internet at the same time I was accessing the WiFI-based Kiwi. The Kiwi started dropping audio. Ping latency went from 10 msec to one second (factor of 100!) and some ping packets were dropped completely. I was very surprised by this. I thought my router would do a better job. Although maybe it's giving the pings the lowest priority.

    PING kiwi ( 56 data bytes
    Request timeout for icmp_seq 0
    64 bytes from icmp_seq=1 ttl=64 time=252.623 ms
    64 bytes from icmp_seq=2 ttl=64 time=7.648 ms
    Request timeout for icmp_seq 3
    64 bytes from icmp_seq=4 ttl=64 time=10.918 ms
    64 bytes from icmp_seq=5 ttl=64 time=10.097 ms
    64 bytes from icmp_seq=6 ttl=64 time=15.933 ms
    64 bytes from icmp_seq=7 ttl=64 time=131.708 ms
    64 bytes from icmp_seq=8 ttl=64 time=14.283 ms
    64 bytes from icmp_seq=9 ttl=64 time=314.411 ms
    Request timeout for icmp_seq 10
    64 bytes from icmp_seq=11 ttl=64 time=797.184 ms
    Request timeout for icmp_seq 12
    64 bytes from icmp_seq=13 ttl=64 time=6.044 ms
    64 bytes from icmp_seq=14 ttl=64 time=335.230 ms
    64 bytes from icmp_seq=15 ttl=64 time=656.736 ms
    Request timeout for icmp_seq 16
    64 bytes from icmp_seq=16 ttl=64 time=1831.217 ms
    64 bytes from icmp_seq=17 ttl=64 time=1291.563 ms
    64 bytes from icmp_seq=18 ttl=64 time=1058.371 ms
    64 bytes from icmp_seq=19 ttl=64 time=704.786 ms
    64 bytes from icmp_seq=20 ttl=64 time=424.829 ms
    64 bytes from icmp_seq=21 ttl=64 time=678.736 ms
    64 bytes from icmp_seq=22 ttl=64 time=391.440 ms
    64 bytes from icmp_seq=24 ttl=64 time=230.705 ms
    64 bytes from icmp_seq=25 ttl=64 time=895.937 ms
    Request timeout for icmp_seq 26
    64 bytes from icmp_seq=26 ttl=64 time=1332.825 ms
    64 bytes from icmp_seq=28 ttl=64 time=753.534 ms
    64 bytes from icmp_seq=29 ttl=64 time=550.501 ms
    64 bytes from icmp_seq=30 ttl=64 time=546.396 ms
    Request timeout for icmp_seq 31
    64 bytes from icmp_seq=32 ttl=64 time=837.901 ms
    64 bytes from icmp_seq=33 ttl=64 time=771.287 ms
    64 bytes from icmp_seq=34 ttl=64 time=629.390 ms
    64 bytes from icmp_seq=35 ttl=64 time=821.533 ms
    64 bytes from icmp_seq=36 ttl=64 time=425.951 ms
    64 bytes from icmp_seq=37 ttl=64 time=223.340 ms
    Request timeout for icmp_seq 38
    64 bytes from icmp_seq=39 ttl=64 time=649.077 ms
    64 bytes from icmp_seq=40 ttl=64 time=390.581 ms
    64 bytes from icmp_seq=41 ttl=64 time=806.054 ms
    64 bytes from icmp_seq=42 ttl=64 time=105.241 ms
    Request timeout for icmp_seq 43
    64 bytes from icmp_seq=43 ttl=64 time=1633.237 ms
    64 bytes from icmp_seq=44 ttl=64 time=1590.436 ms
    64 bytes from icmp_seq=45 ttl=64 time=1704.122 ms
    64 bytes from icmp_seq=46 ttl=64 time=1575.575 ms
    64 bytes from icmp_seq=47 ttl=64 time=1182.548 ms
    64 bytes from icmp_seq=48 ttl=64 time=990.656 ms
    64 bytes from icmp_seq=49 ttl=64 time=1184.694 ms
    64 bytes from icmp_seq=50 ttl=64 time=860.488 ms
    64 bytes from icmp_seq=51 ttl=64 time=41.630 ms
    64 bytes from icmp_seq=52 ttl=64 time=8.301 ms
    64 bytes from icmp_seq=53 ttl=64 time=22.283 ms
    64 bytes from icmp_seq=54 ttl=64 time=9.939 ms
    64 bytes from icmp_seq=55 ttl=64 time=19.741 ms
    64 bytes from icmp_seq=56 ttl=64 time=10.945 ms
    64 bytes from icmp_seq=57 ttl=64 time=257.120 ms
    64 bytes from icmp_seq=58 ttl=64 time=16.330 ms
    64 bytes from icmp_seq=59 ttl=64 time=39.226 ms
    64 bytes from icmp_seq=60 ttl=64 time=12.156 ms
    64 bytes from icmp_seq=61 ttl=64 time=3.504 ms
    64 bytes from icmp_seq=62 ttl=64 time=14.238 ms
    64 bytes from icmp_seq=63 ttl=64 time=9.122 ms
    64 bytes from icmp_seq=64 ttl=64 time=39.547 ms
    64 bytes from icmp_seq=65 ttl=64 time=39.049 ms
    64 bytes from icmp_seq=66 ttl=64 time=9.560 ms
    64 bytes from icmp_seq=67 ttl=64 time=138.750 ms
    64 bytes from icmp_seq=68 ttl=64 time=39.065 ms
    64 bytes from icmp_seq=69 ttl=64 time=17.564 ms
    64 bytes from icmp_seq=70 ttl=64 time=11.781 ms
    64 bytes from icmp_seq=71 ttl=64 time=133.714 ms

  • edited January 2018

    check out the above link to my SDR and see the issue, it seems to be common on many sdr's , it's not just mine.

    I notice this when I'm at home and in work connected to my own network connecting to other SDRs and in work. 

    Not sure whether i should accept or reject replies so apologies if I'm rejecting and should be accepting. 

    I should also add that I use windows 10 at work and MAC at home. 
  • Ok I should have done this before but I tried on my Iphone X and it's working no problem. Could be a Microsoft issue then alright ? that would not be a surprise. 

    But unfortunately Apple will not allow you to stream Audio from a browser with the screen locked !!!
  • The Issue seems to be with Chrome, at least on my work laptop. Working fine on Edge. 
  • For what it's worth, I tried Firefox and Chrome with OS X and Windows 10 on your Kiwi and had no problems.

  • Thanks, yes I did try another browser on my work laptop, probably should have done this first but I was not having issues at home in chrome nor on the work laptop until yesterday but there's always win 10 updates and you never know if one might screw something up.

    Still does not work on Chrome on my work laptop but not bothered about that. 
  • jksjks
    edited January 2018
    We've had a report that with Firefox, going to Preferences > Privacy & Security > Site Data and then doing a Clear All Data has caused audio and waterfall glitches to disappear. It's difficult for us to understand why this would make any difference. If this makes an improvement in anyone's situation please let us know! There should be a similar setting for other browsers.

  • edited January 2018
    Thanks for that, yes restoring Chrome to default settings fixed the issue, this is strange. I did not have to do it on the MAC it just started working again after I tried it again last night but I had to restore to default on my work laptop. 

    Thanks again.
Sign In or Register to comment.