Implement & auto-select Opus' low delay mode #3753
Conversation
|
So should this be accepted? @davidebeatrici ? |
|
From |
|
It is a large improvement in latency. It decreases 15ms from the round trip. It is auto enabled only for high bitrate in which the difference in latency definitely outweighs the difference in quality. In any case we could change the bitrate minimum at which it is auto enabled to a higher bitrate in order to preserve even more quality.
People aren't using Mumble for studio recording, they're using Mumble for video games in which latency matters a lot. In any case we can always make an option to force disable it.
How is this relevant? |
I agree, a 15 ms difference is significant.
Most people are using Mumble for gaming, however it's also used for podcasts, for example. Adding a new option to disable the low-latency encoding is probably the best solution.
From #3753 (comment):
|
Checkbox in "Audio Input"?
I think you're confusing sampling rate with bitrate. It's unrelated. Mumble always uses 48KHz sampling rate internally but supports up to 96kbit/s bitrate currently (from UI, higher bitrate can be forced from other places). With my changes it still always uses 48KHz sampling rate, but bumps UI-selectable bitrate up to 192kbit/s. Opus also always uses 48KHz sampling rate, but supports up to 510kbit/s bitrate. |
Yes
Huge mistake on my side, sorry. I read "96kbit/s" as 96 KHz and didn't think about the fact that we always use 48000 Hz. I got confused by the numbers being equal to the most common frequencies. If Opus supports up to 510 Kb/s, let's set that as the maximum in the UI. |
|
You don't need to be sorry for something like that :D
I thought about that. But maybe the bar would be ugly and harder to use? I also thought about an idea to enable up to 510kbit/s in the UI only if "Advanced" option is checked, and use 96 or 192kbit/s as maximum otherwise. |
|
Perhaps we should add a |
|
Ok there's now an "allow low delay" option, enabled by default. I think I'm leaving the bitrate limit at 192kbit/s for now for reasons of practicality, QLineEdit could be a good idea but shouldn't we handle that in another issue? Tell me what you think. Do you think this is ready or needs further refinement? |
Yes.
Please add a message for each commit, explaining the changes. |
|
I accepted your changes.
What do you mean? There's already commit messages. |
|
I would squash all the commits into a single one and apply the pull request's message. |
However, my branch is both commits ahead and commits behind. I suppose I have to fix that first. |
|
The remote branch should already be set as upstream, That command will discard your local changes. |
So what's gone wrong here? |
|
I see you pulled from The issue is that you don't have Git set to rebase by default, you can do that with: |
But doesn't that affect future pulls only? What should I do right now that this already happened? |
|
Assuming that |
|
So now it's showing a rebase screen with the contents:
Do I just delete the duplicated ones? Which of the two sets? Just at random? |
|
It shouldn't show a rebase screen after running the two commands, it should pull from Was your local branch diverged from the remote one? |
My branch was commits ahead and commits behind when you told me to squash, as I said, if that's what you mean. My knowledge of Git is very low, if what you said one year ago about you offering to do the Git part instead of me still applies you're quite welcome to solve this mess yourself if you want. |
|
Done. I assumed you have You can check with |
|
Thank you. This is the output:
|
|
You're welcome. Your local repository is configured correctly, next time you want to rebase against |
This part is not valid anymore now that the option is removed, right? |
|
The "After THIS pull request" part is no longer valid. Now there is no option to toggle Music/VOIP, so an accurate description is: Low delay/"Music"/VOIP modes available'. If (>64kbit/s bitrate && low delay allowed), enable Low Delay, else if >32kbit/s bitrate enable "Music", else enable VOIP. Can this be accepted now? |
|
I squashed the commits and updated the message. |
davidebeatrici
changed the title
This commit implements Opus' low delay mode selection, which should result in a big decrease in latency. The bUseOpusMusicEncoding option has been removed, because now the Opus mode is selected depending on the bitrate. The automatic selection aims to decrease the latency while maintaining acceptable quality. The exact values may have to be tuned further for a smarter auto-selection because the low delay mode, while causing a strong decrease in latency, requires an higher bitrate to maintain the same quality; in order to compensate, the maximum bitrate in the UI has been increased to 192 kbit/s. The automatic selection sets: Low-delay mode when the bitrate is >= 64 kbit/s. Music mode when the bitrate is >= 32 kbit/s. VOIP mode when the bitrate is < 32 kbit/s.
|
Thank you very much for your contribution! |
|
@davidebeatrici It seems that now there's a duplicate commit in the Mumble repository |
Partially implements #3502. This pull request implements Opus' low delay mode selection, which should result in a big decrease in latency.
The
bUseOpusMusicEncodingoption has been removed, because now the Opus mode is selected depending on the bitrate. The automatic selection aims to decrease the latency while maintaining acceptable quality.The exact values may have to be tuned further for a smarter auto-selection because the low delay mode, while causing a strong decrease in latency, requires an higher bitrate to maintain the same quality; in order to compensate, the maximum bitrate in the UI has been increased to 192 kbit/s.
The automatic selection sets: