Use 10ms packets for slow Opus decoders

With the old 20ms packets, an FEC block was 80ms of audio data.
This is enough data that waiting for the FEC shards can cause
an audio data underflow. The burst of 80ms of audio data after
reassembly fails can then lead clients to drop samples due to
excessive queued data.
This commit is contained in:
Cameron Gutman 2021-06-07 23:20:40 -05:00
parent 4e7b1e3c37
commit 5a71a4c092

View File

@ -412,13 +412,10 @@ static PSDP_OPTION getAttributesList(char*urlSafeAddr) {
err |= addAttributeString(&optionHead, "x-nv-audio.surround.AudioQuality", "0"); err |= addAttributeString(&optionHead, "x-nv-audio.surround.AudioQuality", "0");
HighQualitySurroundEnabled = false; HighQualitySurroundEnabled = false;
if ((AudioCallbacks.capabilities & CAPABILITY_SLOW_OPUS_DECODER) != 0) { if ((AudioCallbacks.capabilities & CAPABILITY_SLOW_OPUS_DECODER) ||
// Use 20 ms packets for slow decoders to save CPU time ((AudioCallbacks.capabilities & CAPABILITY_SUPPORTS_ARBITRARY_AUDIO_DURATION) != 0 &&
AudioPacketDuration = 20; OriginalVideoBitrate < LOW_AUDIO_BITRATE_TRESHOLD)) {
} // Use 10 ms packets for slow devices and networks to balance latency and bandwidth usage
else if ((AudioCallbacks.capabilities & CAPABILITY_SUPPORTS_ARBITRARY_AUDIO_DURATION) != 0 &&
OriginalVideoBitrate < LOW_AUDIO_BITRATE_TRESHOLD) {
// Use 10 ms packets for slow networks to balance latency and bandwidth usage
AudioPacketDuration = 10; AudioPacketDuration = 10;
} }
else { else {