similar to: Question about PLC of Asterisk

Hi, I have a question about jitterbuffer and PLC. I use Asterisk 1.6.2.0 and 1.6.0.20 or older. I use uLaw. My system map: ============================================================================= [ asterisk 2 ] -- # LOSS # -- # A # -- [ asterisk 1 ] -- # B # -- [ X-lite ] ============================================================================= I use two asterisk server.

Thanks for the reply. I think I'm beginning to understand but can you clarify a bit more. 1) I am confused on "trade error-free quality" part. Basically the encoder is doing something to the encoded data by looking at the SPEEX_SET_PLC_TUNING parameter? 2) How does the receiver side determine whether the packet loss occured or not? It seems only way is assigning

hi, i'd like to ask for a suggestion for implementing PLC (packet lost concealment). right now, i don't have PLC applied in my application. when voice data arrive from the network, i just play it right away. does having PLC require that you play something every interval? like if im expecting a voice packet say every 20ms, then i play something at that rate. either the packet that came

Hi, I've try to enable the new loss concealment code with celt-0.6.1. I've run "configure --enable-new-plc" but I've got a missing plc.c file while compiling. It is also missing for version 0.6.0. Can you release this missing file? Thank you, Pascal CRC

Hi, I have read the mailing list archives and have a question regarding PLC (packet loss concealment).

I've been working on improving packet loss concealment in my VoIP client -- I hadn't actually realized speex performed some PLC until I was looking at nb_decode(). There are two things I'd like to do, and I think both will require some modification to nb_decode() and nb_decode_lost(). - I'd like to have my frames overlap by some number of samples. This is intended to reduce the

I've been working on improving packet loss concealment in my VoIP client -- I hadn't actually realized speex performed some PLC until I was looking at nb_decode(). There are two things I'd like to do, and I think both will require some modification to nb_decode() and nb_decode_lost(). - I'd like to have my frames overlap by some number of samples. This is intended to reduce the

Hello I've been using VoIP over a not so reliable net: I usually get a 5% to 10% packet loss and a very high jitter. I tried several codecs and parameters, and the only thing left to test is PLC (Packet Loss Cancellement). Have the astesrisk and digium people implemented PLC?, Are they implmementing it now? and, if not, Where can i find an implementation? Thanks in advance -- Jorge

Is packet-loss concealment influenced by the complexity setting?

In a fork of seanbright's opus patch for 13 there are further patches for Forward Error Correction and Package Loss Concealment, both of which ought to very useful in voip: https://github.com/traud/asterisk-opus Anybody used these patches ? Puzzled why they weren't committed to the main patch. sean

Hi, I am an engineering student in IIT Guwahati, India. Currently, as a summer project I am working on 'packet loss concealment in voip scenario'. I am eager to know what PLC methods are used at receiver end of speex decoder. And if I could develop some more efficient method I could able to contribute to the speex. Actually, I searched the whole speex manual but failed to find what

Hello everyone, I just wanted to see if anyone else is using PLC on the C55x and having success? I am seeing some issues and was curious if I was doing anything wrong/stupid or maybe I have found a bug? I am using: - the CELT library from OPUS 0.9.5 ( I checked the git repo and no check ins have comments about PLC, I assume it hasn't been updated) - FRAME_SIZE: 240 - PACKET_SIZE:

What do you mean by "implement"? You're just using the Opus built-in PLC (passing NULL), right? The PLC generally attempts to find periodicity and replicate it. I guess if your signal isn't periodic it can lead to a repetition that isn't great. It's something that could probably be improved in the PLC. Cheers, Jean-Marc On 08/25/2015 01:21 PM, Scott Boekweg wrote:

Hi everyone, I'd like to announce CELT 0.7.1, which improves the quality of the packet loss concealment (PLC), but does not change the rest of the codec. For this reason it is the first release NOT to break bit-stream compatibility with the previous release (0.7.0). But I promise not to do it again, the next CELT release will likely break compatibility once again. Note that the PLC

Hello all Firstly thanks to everyone involved for creating CELT. It is really very useful :-) One of my targets is current generation Apple iPod with the fixed point decoder (latest version from website, 0.9.1) Based on my simple time-stamp based profiling of my running app it looks like decoding a null buffer for PLC costs a lot more than decoding a normal buffer. For example a standard

Hi Does anyone know where one can get hold of a G729 codec for asterisk which effectively can do packet loss concealment using Steve Kann's wonderful new Jitter buffer. The 2 versions that I know of, (digium's and the IPP one) do not perform great at PLC, especially with 4 or 5% loss. Thanks in advance. Clive

Hello, I'm attempting to use wine with PLC Programmer, which trying to connect to PLC by COM port. After installation and run, program not detecting com ports. This is HP OmniBook 900 Laptop. PIII 500 Sidux (without desktop environment, just pure xserver) - I'm using this laptop only for this program. I have configured it on XFCE, then deleted it. Program starting after system Boot, and

Hi everyone, I'm happy to announce that Opus 1.5 has just been released. Opus 1.5 is the first release to make extended use of ML in the encoder and decoder. You can read all the details in our demo page at: https://opus-codec.org/demo/opus-1.5/ Major changes since 1.4 include: - Significant improvement to packet loss robustness using Deep Redundancy (DRED) - Improved packet loss

Hi We have implemented Opus Codec with a 48 ksps and 5 ms frame running on a C5535 for a radio link. The decode time takes about 2ms, which is fine. However if PLC enabled and there is a lost packet this increases to over 6 ms, which is a major problem for our radio link. Is there any options / optimisations that make the decode time more equal when a lost packet occurs with PLC? Many thanks

I am specifically using Celt Wideband (48kHz) over WiFi multicast that naturally leads to lost packets and am trying to minimize the impact to the audio. I implemented PLC but the audio it produces is robotic. Have I implemented PLC correctly? Checking the waveform it is using the previous received waveform to fill in a missing packet but not the full waveform so it has to repeat. Basically,