Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redundant UDP packet transmission as a way to decrease packet loss #202

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

florianschmeding
Copy link

This feature adds an option to the user to enable packet redundancy and it uses the native feature of the aoo lib for packet redundancy. UDP packets can get lost or unordered on their way to their destination and redundant packets can decrease overall packet loss and the jitter-buffer size if enough bandwidth is available.

To avoid a mindless activation of this feature the user gets warned twice. Once in the tooltip and furthermore by a specific colored feedback if redundancy levels are set to higher than two.

image
A configured packet redundancy of 4 with colored feedback

@essej
Copy link
Collaborator

essej commented Jun 5, 2023

Interesting! You've actually seen conditions where using the packet redundancy really helps things?

@Spacechild1
Copy link

I'm also interested in scenarios where packet redundancy actually helps to overcome packet loss. AFAICT, most UDP packet loss can be traced back to buffer overflows. Typically, you don't mitigate buffer overflows by sending even more data :-)

@AtmanActive
Copy link

This makes sense in situations where a network is lossy but it has a lot more bandwidth than required, like, for example WiFi, 3G, 5G... If a network can't guarantee that each and every packet can be transmitted successfully, then, by doubling the number of packets sent we double our chances that at least one packet will go through, as one packet may be dropped, but the other one (it's duplicate) may go through. In scenarios where we are using, for example, 256kbps stream, if the network is lossy, the fact that the network advertises bandwidth of several megabits per second doesn't help us at all. But, if we can send duplicates x2 or x4 even, then, we can overcome packet loss on the expense of bandwidth used. So, this is a method of overcoming network loss by sending multiple copies of the same packet. Of course, this is all theory, how does it work in real world - I have no idea.

@knixx-fm
Copy link

knixx-fm commented Mar 17, 2024

Please consider to update the Opus codec for the Sonobus project, because the new release includes alot of functions that improve network stability and audio quality. We might not need a redundant packet transmission anymore.

Some teasers:

  • Significant improvement to packet loss robustness using Deep Redundancy (DRED)
  • Improved packet loss concealment through Deep PLC
  • Low-bitrate speech quality enhancement down to 6 kb/s wideband
  • Improved x86 (AVX2) and Arm (Neon) optimizations
  • Support for 4th and 5th order ambisonics

https://opus-codec.org/release/stable/2024/03/04/libopus-1_5_1.html

https://opus-codec.org/demo/opus-1.5/

@cbxk1xg
Copy link

cbxk1xg commented Mar 22, 2024

Please consider to update the Opus codec for the Sonobus project, because the new release includes alot of functions that improve network stability and audio quality. We might not need a redundant packet transmission anymore.

Some teasers:

* Significant improvement to packet loss robustness using Deep Redundancy (DRED)

* Improved packet loss concealment through Deep PLC

* Low-bitrate speech quality enhancement down to 6 kb/s wideband

* Improved x86 (AVX2) and Arm (Neon) optimizations

* Support for 4th and 5th order ambisonics

https://opus-codec.org/release/stable/2024/03/04/libopus-1_5_1.html

https://opus-codec.org/demo/opus-1.5/

That sounds like a really good idea!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants