|
From: | Andrew Bonney |
Subject: | [Linphone-developers] Bugs and patches for L16 mono and stereo audio |
Date: | Sun, 1 Sep 2013 10:23:44 +0000 |
Hi,
We've been wanting to get L16 audio working for a while and noticed a few small issues. These are explained below with patches (attached) which work against the current master branches of mediastreamer2 and oRTP. Feel free to make use of them if they're
useful.
First off, there is currently no protection against oversized packets in the L16 'encoder'. This certainly causes issues for L16 stereo, and can do for mono dependent on the number of samples being sent at a time and the required MTU.
0001-Prevent-MTU-breaches-for-L16-stereo.patch fixes this.
Next, when using SRTP an additional ten bytes are appended to each packet which isn't accounted for in mediastreamer's MTU calculation. The below patch fixes this but also affects cases where SRTP isn't used so there's probably a better way to do it based
on current settings...
0002-Fix-MTU-calculation-for-worst-case-with-SRTP-and-IPv.patch
Finally for mediastreamer2, the PLC component is capable of creating some pretty big rounding errors for L16 44.1kHz (and potentially others), which results in unnecessary insertion of zeros. Changing it to perform calculations based on numbers of samples
seen rather than time periods seems to fix this.
0004-Fix-rounding-errors-in-genericplc-by-calculating-sam.patch
I've also included a small patch for oRTP. Particularly in the case of L16 stereo, the bitrate is so high that there will always be greater than one packet sent per oRTP scheduler tick. This creates a problem as for audio payloads the receiver is currently
forced into non-permissive mode and will assume packets have arrived late. The following fixes that, but there's probably a better way of doing this, perhaps by relating permissive mode to particular payload types or removing this mode forcing code altogether?
0001-Force-permissive-mode-for-high-bitrate-audio-1-packe.patch
With all of the above applied we can get L16 mono or stereo audio working reliably with no glitches. One caveat to this is if the L16 mono and stereo encoders are both enabled in linphone, but appear in a different order in two machines. The call negotiation
will proceed to pick the first L16 encoder/decoder on each side, causing a mono/stereo mismatch between TX and RX and some rather terrible sounding audio. There are a number of potential solutions to this, but for now we're getting around it by only enabling
one of the L16 codecs across all systems at any one time.
Cheers,
Andrew
---------------------------- --------------------- |
0001-Force-permissive-mode-for-high-bitrate-audio-1-packe.patch
Description: 0001-Force-permissive-mode-for-high-bitrate-audio-1-packe.patch
0001-Prevent-MTU-breaches-for-L16-stereo.patch
Description: 0001-Prevent-MTU-breaches-for-L16-stereo.patch
0002-Fix-MTU-calculation-for-worst-case-with-SRTP-and-IPv.patch
Description: 0002-Fix-MTU-calculation-for-worst-case-with-SRTP-and-IPv.patch
0004-Fix-rounding-errors-in-genericplc-by-calculating-sam.patch
Description: 0004-Fix-rounding-errors-in-genericplc-by-calculating-sam.patch
[Prev in Thread] | Current Thread | [Next in Thread] |