[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Linphone-developers] Bugs and patches for L16 mono and stereo audio

From: Andrew Bonney
Subject: [Linphone-developers] Bugs and patches for L16 mono and stereo audio
Date: Sun, 1 Sep 2013 10:23:44 +0000

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...

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.

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?

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.




This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.


Attachment: 0001-Force-permissive-mode-for-high-bitrate-audio-1-packe.patch
Description: 0001-Force-permissive-mode-for-high-bitrate-audio-1-packe.patch

Attachment: 0001-Prevent-MTU-breaches-for-L16-stereo.patch
Description: 0001-Prevent-MTU-breaches-for-L16-stereo.patch

Attachment: 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

Attachment: 0004-Fix-rounding-errors-in-genericplc-by-calculating-sam.patch
Description: 0004-Fix-rounding-errors-in-genericplc-by-calculating-sam.patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]