linphone-developers
[Top][All Lists]
Advanced

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

RE: [Linphone-developers] "Must catchup" Warning


From: Guillaume GOURAT
Subject: RE: [Linphone-developers] "Must catchup" Warning
Date: Wed, 4 May 2005 18:20:19 +0200

Hi,

I have identified the cause of the synchronization loose when playing dtmf :

The arm processor does't have FPU unit and all FP instruction are emulated
by the linux kernel. The dtmf generation is realised with floatting point
calculation. I have modified the dtmf generation code to use fixed point and
the problem seem to be solved. The patch isn't beautifull by it work. I
think that it require a rework before to be integrated to the linphone
source code (especially the sinus table generation). If i have the time to
do  this i will transmit you the new patch. The problem when playing ring
seem to come from a too slow file read (on my system the ring wav file are
stored in a compressed flash file system).

By the way and for the same reason (fp problem on arm), the speex codec use
fixed point calculation on arm processor.
The speex library have two interface for encoding/decoding (with float
sample or short sample) :

/** Uses an existing encoder state to encode one frame of speech pointed to
by
    "in". The encoded bit-stream is saved in "bits".
 @param state Encoder state
 @param in Frame that will be encoded with a +-2^16 range
 @param bits Bit-stream where the data will be written
 */
int speex_encode(void *state, float *in, SpeexBits *bits);

/** Uses an existing encoder state to encode one frame of speech pointed to
by
    "in". The encoded bit-stream is saved in "bits".
 @param state Encoder state
 @param in Frame that will be encoded with a +-2^16 range
 @param bits Bit-stream where the data will be written
 */
int speex_encode_int(void *state, short *in, SpeexBits *bits);

/** Uses an existing decoder state to decode one frame of speech from
 * bit-stream bits. The output speech is saved written to out.
 *
 * @param state Decoder state
 * @param bits Bit-stream from which to decode the frame (NULL if the packet
was lost)
 * @param out Where to write the decoded frame
 * @return return status (0 for no error, -1 for end of stream, -2 other)
 */
int speex_decode(void *state, SpeexBits *bits, float *out);

/** Uses an existing decoder state to decode one frame of speech from
 * bit-stream bits. The output speech is saved written to out.
 *
 * @param state Decoder state
 * @param bits Bit-stream from which to decode the frame (NULL if the packet
was lost)
 * @param out Where to write the decoded frame
 * @return return status (0 for no error, -1 for end of stream, -2 other)
 */
int speex_decode_int(void *state, SpeexBits *bits, short *out);

I have added one paramter (SPEEX_INT) that permit to choose the speex
interface to use. (CFLAGS=-DSPEEX_INT ./configure ...)
I think that it can be judicious to use only the "int" interface in linphone
because if speex is compiled to use floating point, [encode/decode]_int
will convert short sample to float and call the internal processing
function. This is the work actually realized in the linphone speex ms
filter.

Thanks,

Guillaume GOURAT
NexVision.

> -----Message d'origine-----
> De : 
> address@hidden
> u.org 
> [mailto:linphone-developers-bounces+guillaume.nexvision2=free.
> address@hidden De la part de Simon Morlat
> Envoyé : vendredi 22 avril 2005 12:43
> À : address@hidden
> Cc : Guillaume GOURAT
> Objet : Re: [Linphone-developers] "Must catchup" Warning
> 
> hi,
> 
> Linphone says it's late in processing audio data. This may 
> have two origins:
> - 100% cpu  (processor not enough performant for the codec processing)
> - blocking syscalls (especially ones for sound I/O).
> 
> Simon
> 
> Le Lundi 18 Avril 2005 15:17, Guillaume GOURAT a écrit :
> > Hi,
> >
> > I have an arm 920t platform (samsung s3c2410) with the last 
> version of 
> > alsa but I use OSS emulation because i have an issue when 
> using alsa 
> > native interface. I have compiled linphone, it work but i 
> have some problems :
> >
> > I have a lot of "Must catchup" Warning. What is the cause 
> of this warning ?
> > It appear randomly during the call, or systematically when playing 
> > ring or dtmf.
> >
> > [root@(none) /root]$linphonec
> > Message:Found /dev/dsp.
> > Warning:dsp block size set to 2048.
> > DEBUG: [get_output_if] connect: Network is unreachable 
> Message:Adding 
> > new codec PCMU/8000 Message:Adding new codec GSM/8000 
> Message:Adding 
> > new codec PCMA/8000 Message:Adding new codec speex/8000 
> Message:Adding 
> > new codec speex/16000 Message:Adding new codec 1015/8000 Ready.
> > linphonec> c sip:address@hidden
> > Contacting  sip:address@hidden
> > Warning:Local loopback network only !
> > linphonec> Message:CALL_RINGING
> >
> > Message:Remote ringing...
> > Warning:dsp block size set to 2048.
> > Message:ms_filter_add_link: ringplay,0 -> OssWrite,0 
> Message:Opening 
> > sound card [/dev/dsp (Open Sound System)] in playback mode with 
> > stereo=0,rate=8000,bits=16 Warning:dsp block size set to 2048.
> > Message:dsp blocksize is 2048.
> > Warning:Must catchup 106 miliseconds.
> > Warning:Must catchup 89 miliseconds.
> > Warning:Must catchup 71 miliseconds.
> > Warning:Must catchup 54 miliseconds.
> > Message:CALL_ANSWERED
> >
> > Connected.
> > Message:Mediastreamer processing thread is exiting.
> > Message:Closing writing channel of soundcard.
> > Warning:Local loopback network only !
> > Message:ms_filter_add_link: OssRead,0 -> MULAWEncoder,0
> > Message:ms_filter_add_link: MULAWEncoder,0 -> RTPSend,0
> > Message:ms_filter_add_link: RTPRecv,0 -> MULAWDecoder,0
> > Message:ms_filter_add_link: MULAWDecoder,0 -> OssWrite,0 
> > Message:Opening sound card [/dev/dsp (Open Sound System)] 
> in capture 
> > mode with stereo=0,rate=8000,bits=16 Warning:dsp block size set to 
> > 2048.
> > Message:dsp blocksize is 2048.
> > Message:Opening sound card [/dev/dsp (Open Sound System)] 
> in playback 
> > mode with stereo=0,rate=8000,bits=16 Message:CALL_STARTAUDIO
> >
> > Warning:Must catchup 114 miliseconds.
> > Warning:Must catchup 96 miliseconds.
> > Warning:Must catchup 78 miliseconds.
> > Warning:Must catchup 58 miliseconds.
> > Warning:Must catchup 111 miliseconds.
> > Warning:Must catchup 93 miliseconds.
> > Warning:Must catchup 74 miliseconds.
> > Warning:Must catchup 56 miliseconds.
> > Message:Receiving dtmf 8.
> > Warning:Must catchup 79 miliseconds.
> > Warning:Must catchup 60 miliseconds.
> > Warning:Must catchup 121 miliseconds.
> > Warning:Must catchup 311 miliseconds.
> > Warning:Must catchup 296 miliseconds.
> > Warning:Must catchup 371 miliseconds.
> > Warning:Must catchup 354 miliseconds.
> > Warning:Must catchup 339 miliseconds.
> > Warning:Must catchup 321 miliseconds.
> > Warning:Must catchup 304 miliseconds.
> > Warning:Must catchup 288 miliseconds.
> > Warning:Must catchup 272 miliseconds.
> > Warning:Must catchup 255 miliseconds.
> > Warning:Must catchup 238 miliseconds.
> > Warning:Must catchup 219 miliseconds.
> > Warning:Must catchup 200 miliseconds.
> > Warning:Must catchup 181 miliseconds.
> > Warning:Must catchup 162 miliseconds.
> > Warning:Must catchup 143 miliseconds.
> > Warning:Must catchup 123 miliseconds.
> > Warning:Must catchup 104 miliseconds.
> > Warning:Must catchup 84 miliseconds.
> > Warning:Must catchup 64 miliseconds.
> > Message:Receiving dtmf 9.
> > Warning:Must catchup 77 miliseconds.
> > Warning:Must catchup 59 miliseconds.
> > Warning:Must catchup 130 miliseconds.
> > Warning:Must catchup 201 miliseconds.
> > Warning:Must catchup 186 miliseconds.
> > Warning:Must catchup 259 miliseconds.
> > Warning:Must catchup 243 miliseconds.
> > Warning:Must catchup 226 miliseconds.
> > Warning:Must catchup 209 miliseconds.
> > Warning:Must catchup 189 miliseconds.
> > Warning:Must catchup 170 miliseconds.
> > Warning:Must catchup 151 miliseconds.
> > Warning:Must catchup 133 miliseconds.
> > Warning:Must catchup 114 miliseconds.
> > Warning:Must catchup 95 miliseconds.
> > Warning:Must catchup 75 miliseconds.
> > Warning:Must catchup 56 miliseconds.
> >
> >
> > Thanks,
> >
> > Guillaume GOURAT.
> >
> >
> >
> >
> > _______________________________________________
> > Linphone-developers mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/linphone-developers
> 
> 
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers
> 

Attachment: diff-linphone-1.0.1-nx1
Description: Binary data


reply via email to

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