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

Jitteryness simple fix #46

Closed
kestasjk opened this issue Jul 19, 2019 · 4 comments · Fixed by #54
Closed

Jitteryness simple fix #46

kestasjk opened this issue Jul 19, 2019 · 4 comments · Fixed by #54

Comments

@kestasjk
Copy link

Hi, we're using this in a new application and the jitter was quite an issue, but I found (by accident) that if I paused the application for a moment then continued everything would be fine.

After playing around with AudioBuffer.cs to try and make it buffer more data without luck I found that if AudioBuffer detects when Read() isn't returning enough info it should just set a flag "IsJitterring", which can be made accessible via the MumbleSharp Model/User.cs class.

Then the EncodedVoiceDelegate looks for user.IsJittering , and if so it pauses the user, turns the jitter flag off, and saves the current time. Then once it has been, say, 100-200 ms since the pause started the user is unpaused and the voice is smooth again. I am testing this out now but it seems pretty robust.

@martindevans
Copy link
Owner

What you're describing there is essentially a dynamic jitter buffer - as network conditions worsen you deliberately delay the audio so that there's more of a buffer between playback and the bad network conditions. Usually this is done by measuring the arrival time of packets (which should be constant), calculating jitter from that and delaying playback accordingly. Really advanced jitter buffers will even strentch or squeeze samples as they're playing back to grow or shrink the buffer in accordance with real-time jitter measurements!

Would you be willing to put in a PR which delays the playback of all voice by a small fixed amount (say 50ms) and making that delay configurable? We can then come back later (or you can in a followup PR if you like) and add something that measures network jitter and sets the delay.

@kestasjk
Copy link
Author

I actually didn't have much luck adding a static delay. What I'll probably do is fork and commit all changes to the fork, then you can pick and choose what you want or decide to do things differently. What I commit will (eventually) be a production PTT system used over wifi so it should at least give something to compare to.

@trevorirwin
Copy link
Contributor

I've made some progress on this, see #52 for details!

@Meetsch Meetsch linked a pull request Jun 9, 2020 that will close this issue
@dextercai
Copy link

Can this problem be fixed by referring to "BananaHemic/Mumble-Unity"?

@Meetsch Meetsch closed this as completed Mar 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants