[Top][All Lists]

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

Re: [Linphone-developers] sound card block size different.

From: Kosta Welke
Subject: Re: [Linphone-developers] sound card block size different.
Date: Mon, 06 Mar 2006 21:14:36 +0100
User-agent: Thunderbird 1.5 (X11/20060113)

meng hongling wrote:
> I could set up the call,but the sound is not very good.Sound
> delay is obvious with distorted sound.I don't know why this happened.
> I only found that sound card block size is different,my PC is 512 while 
> my embedded board is 8192.Is this the reason for bad sound effect.

What board are you using? I've experienced similar problems with the
Motorola A780 Linux phone. To me it seems that the problem is not the
block size but an unrealiable system timer. (But I'll investigate on this)

My symptoms were:
- No sound output on embedded device (packets got too old and were
discarded before they could be played)
- Disrupted sound output on the other side

I was able to make things better by using two hacks:
in mediastreamer/msrtpsend.c, around line 90:
comment out the if/then/else block and replace it with
r->ts = clockts;

in oRTP/src/rtpsession.c, around line 1420:
-       session->rtp.rcv_last_ts = ts;
-       mp = rtp_getq (&session->rtp.rq, ts,&rejected);
+       queue_t *q = &session->rtp.rq;
+       if (!qempty(q))
+         {
+           gint newest = ((rtp_header_t*) qlast(q)->b_rptr)->timestamp;
+           ts = newest + 1024; //arbitrary value
+           mp = rtp_getq (&session->rtp.rq, ts,&rejected);
+         }

This just selects a fairly new packet to be used for sound output, with
some sort of jitter correction delay.

If I find a better fix, I'll let you know.

btw, Simon, the RFC says (5.1 RTP Fixed Header Fields):
"If RTP packets are generated
 periodically, the nominal sampling instant as determined from
 the sampling clock is to be used, not a reading of the system
 clock. As an example, for fixed-rate audio the timestamp clock
 would likely increment by one for each sampling period.  If an
 audio application reads blocks covering 160 sampling periods
 from the input device, the timestamp would be increased by 160
 for each such block, regardless of whether the block is
 transmitted in a packet or dropped as silent."

Is this what you are doing with r->ts+=r->ts_inc; in get_new_timestamp()?


reply via email to

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