[pjsip] How to handle silence / NONE frames?/-clock-rate=8000?

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

 



 Hi Benny,
It is working better now, but I am getting clicks in speech due to packet
loss.

Tests from my app and PJSUA gave the following results only
when -clock-rate=8000

(sip:904 at mouselike.org)

pkt loss=39 (2.5%),

pkt loss=79 (4.6%),

pkt loss=51 (3.2%)

CPU use remains low (<2%) but it seems as though re-sample may be affecting
the thread receiving the packet.




Do you think the performance would be better if the conference bridge
remained at 16khz and the port does the re-sampling?







B.T.W.
>Frankly this could be a bug (see below). But even if frame.type is
>NONE, the frame.size would (normally!) be zero too, so it's not a
>major bug.



In my port I found frame.size to be 320 even when frame.type is NONE.







Regards

Lafras
















----- Original Message -----
From: "Benny Prijono" <bennylp@xxxxxxxxx>
To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org>
Sent: Tuesday, October 02, 2007 12:00 PM
Subject: Re: [pjsip] How to handle silence / NONE frames?


> Lafras Henning wrote:
> > Thanks  Benny,
> >
> > My misunderstanding was assuming L145  if (snd_port->plc)  - would be
true
> > but instead
> >  pj_bzero(output, size); is executed.
>
> Yes. The default behavior is to send over zero frame to the sound
> device if the stream doesn't return any frame (that is when
> frame->type is NONE).
>
> > In wav_writer.c and mem_capure.c the sound buffer is used without being
> > zero'd regardless of the  frame.type.
>
> Frankly this could be a bug (see below). But even if frame.type is
> NONE, the frame.size would (normally!) be zero too, so it's not a
> major bug.
>
> The effect of this bug is no silence would be written to the WAV
> file, if the silence is expressed with frame.type=NONE rather than
> zero frame, since when frame.type is NONE, the WAV writer won't
> write any data to the file.
>
> For now, or at least in pjsua, this bug does not manifest itself
> since WAV writer is connected to the conference bridge which doesn't
> emit NONE frame.
>
> > Ignoring frame.type or zero-ing the buffer fixes the problem in my
> > application, which is better though?
>
> Zero-ing the buffer is better.
>
> If you ignore frame.type (and instead only rely to frame.size to be
> zero), there is a chance that you might miss some silence frames
> like the WAV writer bug above.
>
>
> > I see  snd_port->plc  is only created (depending on options options)
when
> > snd_port is created.
>
> Yes.
>
> > So do the codecs that don't have built-in PLC (g711 and gsm), rely on
> > snd_port->plc? Or do they have their own plc?
>
> gsm and g711 instantiate their own plc, separate than the plc in
> snd_port. I used plc in snd_port mainly to experiment with plc
> algorithm.
>
> But looking at the gsm and g711 source codes again, it looks like by
> default the plc is disabled too, since pjsip 0.7!
>
> > Do I then need a PLC in my port at all?
>
> No, you don't need plc. PLC should only be used in stream.c, since
> once it gets over stream.c, there shouldn't be any frame lost!
>
> regards,
>   -benny
>
>
> > Regards
> > Lafras
> >
> >
> >
> > ----- Original Message -----
> > From: "Benny Prijono" <bennylp@xxxxxxxxx>
> > To: "pjsip embedded/DSP SIP discussion" <pjsip at lists.pjsip.org>
> > Sent: Tuesday, October 02, 2007 8:40 AM
> > Subject: Re: [pjsip] How to handle silence / NONE frames?
> >
> >
> >> Lafras Henning wrote:
> >>> Hi Benny,
> >>>
> >>> In my application I get a scratching/clicking noise when the other
side
> >>> sends silence packets, On but on PJSUA no scratching occurs.
> >>>
> >>> My application is getting PJMEDIA_FRAME_TYPE_NONE frames during this
> >>> silence,
> >>>
> >>> sound_port.c simply applies PLC to these packets, but surly there is a
> >>> difference between missing and silence packets?
> >>>
> >>> What would you recomend?
> >> There are two kind of PLCs in pjmedia, first is the PLC that comes
> >> with the codec (such as Speex and iLBC), and the other is the
> >> generic PLC that is used in sound_port.c and also by codecs that
> >> don't have built-in PLC (g711 and gsm).
> >>
> >> The generic PLC is really bad, as it only replays the previous frame
> >> (at lower intensity), and normally this creates the clicking noise.
> >> So you should not use this. The sound_port.c also does not use this
> >> by default either.
> >>
> >> So if you don't hear clicking noise in pjsua, could it probably
> >> because pjsua uses Speex or iLBC (with their built-in PLC)?
> >>
> >> Indeed there is a different treatment for missing and silence
> >> packets, this processing is done in stream.c, by looking at the
> >> return status of the jitter buffer. The former will trigger the
> >> codec's PLC, while the later won't.
> >>
> >> What kind of silence frames did you get?
> >>
> >> regards,
> >>   -benny
> >>
> >>
> >>> Regards
> >>> Lafras
> >>>
> >>> static pj_status_t zxTDM_put_frame( pjmedia_port *port,
> >>>       const pjmedia_frame *frame)
> >>> {
> >>>     port_data *zxTDM = port->port_data.pdata;
> >>>     pj_int16_t *samples = frame->buf;
> >>>     unsigned i, count;
> >>>
> >>>     if (zxTDM->Active!=1)  return PJ_SUCCESS;
> >>>     if (zxTDM->Fifo==NULL) return PJ_SUCCESS;
> >>>     if (zxTDM->Fifo->Active!=1) return PJ_SUCCESS;
> >>>
> >>>      if (frame->type != PJMEDIA_FRAME_TYPE_AUDIO)
> >>>       {
> >>>        pjsua_NonAudioFrames++;
> >>>        pjsua_NonAudioFramesType = frame->type; //yep getting 0
> >>>        return PJ_SUCCESS; //just ignor
> >>>       }
> >>>     /* Get number of samples */
> >>>     count = frame->size / 2 / port->info.channel_count;
> >>>     //It is possible to improve the performance of this critical
section
> >>> by bringing in the code from zxSimpleFifo and optimising it
> >>>     //  to optimize similar to FifoBufferUnit- Calculate 2 blocks
(upto
> >>> end and from begining) that can be copied without testing - check
> >>> PeekBuffer()
> >>>     for (i=0; i<count; ++i) {
> >>>  zxFifo_PostByte(&zxTDM->Fifo->Rx,pjmedia_linear2alaw(*samples));
> >>>  zxTDM->Fifo->Rx.TxCounter--;
> >>>  samples++;
> >>>  }
> >>>
> >>> //save data for PLC
> >>>
> >>>     if (zxTDM->plc)
> >>>  pjmedia_plc_save(zxTDM->plc, (pj_int16_t*)frame->buf); //missing
> >>> packets are fixed from the other side of the fifo.
> >>>
> >>> //NOW perform Echo cancelation //taken from sound_port.c
> >>>     if (zxpjsua_EchoCanceler) pjmedia_echo_playback(zxTDM->ec_state,
> >>> (pj_int16_t*)frame->buf);
> >>>
> >>>     return PJ_SUCCESS;
> >>> }
> >>>
> >>>
>
>>> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Visit our blog: http://blog.pjsip.org
> >>>
> >>> pjsip mailing list
> >>> pjsip at lists.pjsip.org
> >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> >>
> >> --
> >> Benny Prijono
> >> http://www.pjsip.org
> >>
> >>
> >> _______________________________________________
> >> Visit our blog: http://blog.pjsip.org
> >>
> >> pjsip mailing list
> >> pjsip at lists.pjsip.org
> >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
> >>
> >
> >
> > _______________________________________________
> > Visit our blog: http://blog.pjsip.org
> >
> > pjsip mailing list
> > pjsip at lists.pjsip.org
> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
> --
> Benny Prijono
> http://www.pjsip.org
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux