v1.115: reduced audio latency, especially for local connections

jksjks
edited August 2017 in KiwiSDR Discussion
In this release you should notice reduced audio latency, i.e. the delay between changing something like the frequency or mode and the resulting change in audio. This is especially true for local connections. A connection where the Kiwi and computer running the browser are on the same local subnet. The audio buffering is reduced even more for this case.

To switch back to the previous behavior click on the "Snd" button (above the "More" button) so it shows white instead of green and then reload the page. This setting is saved in a cookie across reloads like some of the other buttons are.

Comments

  • G8JNJG8JNJ
    Hi John,

    The new reduction in audio latency makes almost 1 second difference on my local network which is great :-)

    However I don't know if it is just me, but unfortunately the audio 'stuttering' when the waterfall is moved or zoomed or the frequency is changed, which was previously tolerable is now very noticable and somewhat irritating if you scan up and down the frequency range with the left and right arrows.

    Has anyone else noticed this ?

    Regards,

    Martin - G8JNJ




  • jksjks
    edited August 2017
    What kind of computer running the browser? If you were getting some stuttering before then it sounds like it's a problem with the browser not having enough CPU to handle the rendering and yet keep up with audio buffering.

    I'm running Safari / Firefox / Chrome on a two year old 2.5 GHz core i7 MacBook Pro and I can zoom, pan and scroll all day without dropping any audio using the new buffering scheme on a local connection. But that's just one use case of course.

    Do you get audio under/over-run messages or just drop-outs?

  • sv1btlsv1btl
    It's working just GREAT!!! 
  • sv1btlsv1btl
    The next step will be maybe to increase listeners' slots!... 
  • G8JNJG8JNJ
    Hi John,

    Very odd - I'm using a Desktop Intel i7-2600 @ 3.4GHz 16GB RAM running Win 7 pro 64 bit.

    The problem was really bad this morning when I was using Chrome. I just tried Firefox and it was better, although I get both Audio under and over run messages in Firefox which I don't get so much when using Chrome.

    If I use the -ve magnifying glass to zoom out to say two levels before the full 0-30MHz spectrum is displayed the 'stuttering' lasts for almost a second.

    I've also tried it on a i5-3320M Laptop @ 2.6GHz with 8 GB of RAM running Win 7 pro 64 Bit using Chome and it's also quite bad and displaying audio under / overrun when I zoom. It's also randomly throwing up under / over run messages and stuttering when it's just listening to noise.

    If I use Firefox on the Laptop the audio tends to mute for a short period (can be up to two seconds) rather than 'stutter'. 

    In all cases the effect is noticeable with the original white Snd setting but it's much worse when using the new option.

    Regards,

    Martin - G8JNJ
  • G8JNJG8JNJ
    Hi John,

    I have emailed you a short video screen grab with audio.

    Regards,

    Martin - G8JNJ
  • W5UXHW5UXH
    Wow, this was my one thing that I wished for, I agree with SV1BTL, it is the icing on the cake.  Never had any stutter here either.  Thanks.

  • G8JNJG8JNJ
    Hi John,

    I just tried it on my iPad Mini using both Chrome and Safari, using a strong WiFi signal and logged in via the local IP addresses.

    If I listen to a good quality Broadcast station, the audio is chopping up almost continuously when the waterfall is zoomed out further than Z8. 

    At Z7 it's showing audio overrun every second.

    With the original setting the audio is perfect a even at Z0.

    Regards,

    Martin - G8JNJ
  • BjarneBjarne
    Likely the same problems as Martin. Audio sample here: https://www.dropbox.com/s/c1wrj04pzbp53ez/kiwisdr_9480_v1115.mp3?dl=0

    Never had this before as I can remember. Surface Pro 3, Chrome.

    Regards,
    Bjarne
  • jksjks
    With the previous scheme selected ("Snd" button set to white then a reload) does it behave as before? i.e. from your perspective have I broken the old behavior somehow with the changes?

  • BjarneBjarne
    Yes, selecting Snd and reload seems to have "normal" audio. I missed the "reload" in your first posting.
  • BjarneBjarne
    It should be noted that I experience the same behaviour (both with audio and less latency) on remote and local connections.
  • jksjks
    Okay, I'm going to try something different for today's release.

    G8JNJ
  • G8JNJG8JNJ
    Hi John,

    That's a lot better :-)

    Most of the time it's now hardly noticable, but it's still quite obvious when zooming between levels Z5 - Z8 for some reason. Z0 - Z5 is OK 'ish' .

    Using the iPad mini displaying 0-30MHz on the waterfall the audio now only occasionally cuts out.

    So whatever you did seems to have made a big improvement - now that this gives a clue to the problem, are there any more tweaks you could make to fine tune it further ?

    Regards,

    Martin - G8JNJ
  • BjarneBjarne
    Only a brief remote test: Very much better, though I didn't test all zoom levels like Martin did. Will check out both local and remote later today.

    Bjarne
  • M0RZFM0RZF
    Works perfect on V1.116 for me.

    The lower latency allows it to be used with a co-located transmitter in a live QSO. A fun echo effect can be created, the shorter delay/latency is similar to the time taken by a radio signal to go around the earth!

    73, Rob
    M0RZF

  • ic8pofic8pof
    HI , the improvement is OK.
    Could this buffer be still reduced  ?
    ..... for the series: we are never happy of what we have ...
    Phil
  • jksjks
    No, there will be no further attempts to reduce the buffer size manually.

    Using trial-and-error to reduce the buffer size "until it starts failing for some people" is an extremely bad idea. You can never be certain what you've done will work for everyone. So you get stuck spending all your time making small adjustments trying to please everyone for increasingly small returns.

    The recent change was simple and worth doing: using a reduced buffer size for a detected local connection. But anything beyond that would require some technique to characterize the network channel and adjust the buffering dynamically. Like what Skype or similar programs do. But this is extremely complicated (look how many _years_ it took for Skype to deal with the problem reasonably)


  • ic8pofic8pof
    Of course you are right John.
    In the vx117 I am noting that the time taken to change from a cw station to another in the local lan has rised a little compared to the x116.
    It seemed to me that the 116 was faster in change from 117... or no ?
    Phil
  • jksjks
    For a local LAN connection (same ip subnet) it should be HALF what it was before, e.g. 700 msec instead of 1.4 sec.

  • WA2ZKDWA2ZKD
    is the [SND] still needed?
  • jksjks
    No one has complained that they needed to turn the new sound latency changes off (by toggling SND from green to white). So I'll probably remove the button in the next release.

  • G8JNJG8JNJ
    Hi All,

    Sorry folks but I still use the SND button and generally leave it on white when using the SDR on a local connection, as I find the remaining mild amount of audio stuttering when zooming etc. to be more annoying than any improvement in audio latency.

    It also helps to be able to use the white mode on my iPad Mini, which hasn't really got enough grunt when the full spectrum is displayed.

    However if the consensus is that it should be removed then I would accept that decision, although I don't see that keeping the option causes any harm or adds any significant load on the limited Beagle resources (but I may be wrong).

    Regards,

    Martin - G8JNJ

     


  • WA2ZKDWA2ZKD
    If the [SND] button is to remain, could it get aligned in the window! :-)   
  • M0TAZM0TAZ
    If it remains, could you add some "hover over" text please like the other buttons.
Sign In or Register to comment.