Allow adjustment to buffer / audio delay in web client

[sbridger]

It is very unpleasant/difficult to use remote rx with a local transmitter due to the 2 second audio delay. Having used a direct analog remote the usability is hugely improved with zero lag.
Long buffering might be useful for people who are only listening, but it needs to be reduced as much as possible when you are also transmitting, and moreso when you are using both a local rx and the remote rx at the same time.
Making it adjustable would let people set a tolerable level of stuttering - HF SSB is not exactly high quality anyway.

Doing simple tests: Unplugging the network or clicking the mute button, seems to show that there is ~2secs audio delay between the web client and speaker.
Some other web clients e.g. skype don't have this huge buffer delay, whilst some e.g. mp3 players seem to.

Perhaps rather than buffering being set, there are different sound api's for buffered music type sound vs real-time type telephony. In that case it would be good to have a switch that can select realtime sound

Target audience
Hams - transmitting locally, rx from remote and local.

[jketterl]

I'm sorry, but there's nothing to adjust here. The application already tries to keep the audio buffer down to a minimum, and only buffers if the audio data is not arriving in time.

By unplugging the network cable you have created an artificial network latency that filled up the buffer to its maximum, so that is not really a usable measurement.

Other applications do not need to deal with the sample rates that an SDR delivers and are therefor able to achieve better latencies. A lack of CPU power on the receiver end increases the chance of audio data arriving late, thus increasing the necessary buffer size.

If you do have any reasonable input about other technologies and how they would improve the latency, please feel free to comment on the existing issues: See #274 and #220.

[sbridger]

Bear in mind that I'm trying to infer how the OpenWebRX architecture works. I don't know if the buffering we are discussing is something you specify, or something completely hidden/controlled by the tcp stack/browser.

By unplugging the network cable you have created an artificial network latency that filled up the buffer to its maximum, so that is not really a usable measurement.

OK, so I did some experiments. Laptops on wifi seem to have a longer buffer. Cabled connections have a shorter (eg 1 sec) buffer, but after I have unplugged them it expands to almost 5 secs.

The buffer size appears to expand and not shrink down again. i.e. it was 1 sec before I unplugged the cable. Now several minutes later it is 4 secs. Again in the wifi or mobile situation, a brief weak spot or cell transition will cause unacceptable delay afterwards, even though the network is now stable and doesn't need the excess buffer.

If I am having a conversation, some amount of dropout is less of a problem than latency (HF ssb is already full of lightning, fades etc). The buffer size appears to expand and not shrink down again. i.e. it was 1 sec before I unplugged the cable. Now several minutes later it is 4 secs. Again in the wifi or mobile situation, a brief weak spot or cell transition will cause unacceptable delay afterwards, even though the network is now stable and doesn't need the excess buffer.
I would like to manually set the buffering or to manually set a maximum the buffer can expand to.
The present situation where the buffer might expand to 5 secs when I move to a weak wifi location is far worse than the audio dropping out, and I move back to a strong network signal position.

It also plays for 2 seconds after I press the mute button.
I now assume that the client is just getting an audio stream and a waterfall stream (together or separate?) from the server. All controls -mute, squelch etc I assume are acting at the server.

So it might also be desirable to do a buffer dump on audio affecting UI changes so that changes are effective immediately and the UI seems responsive.

[sbridger]

If you do have any reasonable input about other technologies and how they would improve the latency, please feel free to comment on the existing issues: See #274

Stackoverflow suggests that WebRTC may be the correct solution for the audio transport.

[sbridger]

Thinking more about the TCP vs UDP:
I don't know if the TCP stack per-se is the source of the long and persistent delay. It seems unlikely, as the delay grows to 4 secs after a network unplug, but does not reduce when the reliable network is restored. So it seems likely that while UDP might allow lower latency, that might not be the issue here.

So perhaps what is happening is this:

When the network is broken TCP waits for it's maximum delay and increases it's buffer. Lets call that max 4 secs.
So now the server is streaming audio out at 1sec per second. The client is playing audio packets at 1sec/sec. So once any particular delay has been established it is now fixed - the player is matching the server, and can never catch up and eliminate the delay.

I'm not seeing why the 4 sec block gets established - perhaps it requests 4 secs of retransmissions when the connection restores.

Perhaps the player needs to do a dump after breaks?
Perhaps there needs to be a dump button on the UI that makes the player dump all the buffered packets from the audio player?