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

o00scorpion00o

Constantly since this update ? 

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

o00scorpion00o

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.

jks

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 (192.168.1.103): 56 data bytes

Request timeout for icmp_seq 0

64 bytes from 192.168.1.103: icmp_seq=1 ttl=64 time=252.623 ms

64 bytes from 192.168.1.103: icmp_seq=2 ttl=64 time=7.648 ms

Request timeout for icmp_seq 3

64 bytes from 192.168.1.103: icmp_seq=4 ttl=64 time=10.918 ms

64 bytes from 192.168.1.103: icmp_seq=5 ttl=64 time=10.097 ms

64 bytes from 192.168.1.103: icmp_seq=6 ttl=64 time=15.933 ms

64 bytes from 192.168.1.103: icmp_seq=7 ttl=64 time=131.708 ms

64 bytes from 192.168.1.103: icmp_seq=8 ttl=64 time=14.283 ms

64 bytes from 192.168.1.103: icmp_seq=9 ttl=64 time=314.411 ms

Request timeout for icmp_seq 10

64 bytes from 192.168.1.103: icmp_seq=11 ttl=64 time=797.184 ms

Request timeout for icmp_seq 12

64 bytes from 192.168.1.103: icmp_seq=13 ttl=64 time=6.044 ms

64 bytes from 192.168.1.103: icmp_seq=14 ttl=64 time=335.230 ms

64 bytes from 192.168.1.103: icmp_seq=15 ttl=64 time=656.736 ms

Request timeout for icmp_seq 16

64 bytes from 192.168.1.103: icmp_seq=16 ttl=64 time=1831.217 ms

64 bytes from 192.168.1.103: icmp_seq=17 ttl=64 time=1291.563 ms

64 bytes from 192.168.1.103: icmp_seq=18 ttl=64 time=1058.371 ms

64 bytes from 192.168.1.103: icmp_seq=19 ttl=64 time=704.786 ms

64 bytes from 192.168.1.103: icmp_seq=20 ttl=64 time=424.829 ms

64 bytes from 192.168.1.103: icmp_seq=21 ttl=64 time=678.736 ms

64 bytes from 192.168.1.103: icmp_seq=22 ttl=64 time=391.440 ms

64 bytes from 192.168.1.103: icmp_seq=24 ttl=64 time=230.705 ms

64 bytes from 192.168.1.103: icmp_seq=25 ttl=64 time=895.937 ms

Request timeout for icmp_seq 26

64 bytes from 192.168.1.103: icmp_seq=26 ttl=64 time=1332.825 ms

64 bytes from 192.168.1.103: icmp_seq=28 ttl=64 time=753.534 ms

64 bytes from 192.168.1.103: icmp_seq=29 ttl=64 time=550.501 ms

64 bytes from 192.168.1.103: icmp_seq=30 ttl=64 time=546.396 ms

Request timeout for icmp_seq 31

64 bytes from 192.168.1.103: icmp_seq=32 ttl=64 time=837.901 ms

64 bytes from 192.168.1.103: icmp_seq=33 ttl=64 time=771.287 ms

64 bytes from 192.168.1.103: icmp_seq=34 ttl=64 time=629.390 ms

64 bytes from 192.168.1.103: icmp_seq=35 ttl=64 time=821.533 ms

64 bytes from 192.168.1.103: icmp_seq=36 ttl=64 time=425.951 ms

64 bytes from 192.168.1.103: icmp_seq=37 ttl=64 time=223.340 ms

Request timeout for icmp_seq 38

64 bytes from 192.168.1.103: icmp_seq=39 ttl=64 time=649.077 ms

64 bytes from 192.168.1.103: icmp_seq=40 ttl=64 time=390.581 ms

64 bytes from 192.168.1.103: icmp_seq=41 ttl=64 time=806.054 ms

64 bytes from 192.168.1.103: icmp_seq=42 ttl=64 time=105.241 ms

Request timeout for icmp_seq 43

64 bytes from 192.168.1.103: icmp_seq=43 ttl=64 time=1633.237 ms

64 bytes from 192.168.1.103: icmp_seq=44 ttl=64 time=1590.436 ms

64 bytes from 192.168.1.103: icmp_seq=45 ttl=64 time=1704.122 ms

64 bytes from 192.168.1.103: icmp_seq=46 ttl=64 time=1575.575 ms

64 bytes from 192.168.1.103: icmp_seq=47 ttl=64 time=1182.548 ms

64 bytes from 192.168.1.103: icmp_seq=48 ttl=64 time=990.656 ms

64 bytes from 192.168.1.103: icmp_seq=49 ttl=64 time=1184.694 ms

64 bytes from 192.168.1.103: icmp_seq=50 ttl=64 time=860.488 ms

64 bytes from 192.168.1.103: icmp_seq=51 ttl=64 time=41.630 ms

64 bytes from 192.168.1.103: icmp_seq=52 ttl=64 time=8.301 ms

64 bytes from 192.168.1.103: icmp_seq=53 ttl=64 time=22.283 ms

64 bytes from 192.168.1.103: icmp_seq=54 ttl=64 time=9.939 ms

64 bytes from 192.168.1.103: icmp_seq=55 ttl=64 time=19.741 ms

64 bytes from 192.168.1.103: icmp_seq=56 ttl=64 time=10.945 ms

64 bytes from 192.168.1.103: icmp_seq=57 ttl=64 time=257.120 ms

64 bytes from 192.168.1.103: icmp_seq=58 ttl=64 time=16.330 ms

64 bytes from 192.168.1.103: icmp_seq=59 ttl=64 time=39.226 ms

64 bytes from 192.168.1.103: icmp_seq=60 ttl=64 time=12.156 ms

64 bytes from 192.168.1.103: icmp_seq=61 ttl=64 time=3.504 ms

64 bytes from 192.168.1.103: icmp_seq=62 ttl=64 time=14.238 ms

64 bytes from 192.168.1.103: icmp_seq=63 ttl=64 time=9.122 ms

64 bytes from 192.168.1.103: icmp_seq=64 ttl=64 time=39.547 ms

64 bytes from 192.168.1.103: icmp_seq=65 ttl=64 time=39.049 ms

64 bytes from 192.168.1.103: icmp_seq=66 ttl=64 time=9.560 ms

64 bytes from 192.168.1.103: icmp_seq=67 ttl=64 time=138.750 ms

64 bytes from 192.168.1.103: icmp_seq=68 ttl=64 time=39.065 ms

64 bytes from 192.168.1.103: icmp_seq=69 ttl=64 time=17.564 ms

64 bytes from 192.168.1.103: icmp_seq=70 ttl=64 time=11.781 ms

64 bytes from 192.168.1.103: icmp_seq=71 ttl=64 time=133.714 ms

o00scorpion00o

http://emeraldsdr.ddns.net:8073/

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. 

o00scorpion00o

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 !!!

o00scorpion00o

The Issue seems to be with Chrome, at least on my work laptop. Working fine on Edge. 

jks

For what it's worth, I tried Firefox and Chrome with OS X and Windows 10 on your Kiwi and had no problems.

o00scorpion00o

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. 

jks

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.

o00scorpion00o

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.