The .89 sec consumed by waveInStart() causes clipping of the audio so the 1st few words spoken are lost. The rest of the call sounds fine. I did 10 calls and 3 calls suffering from this problem. This clipping is a small problem but it can cause complaints. My main problem is the occasionally poor timing in wmme_dev thread. This affects the entire call and trashes the voice quality. The 77ms is just an average for that call which is calculated by totalling the number of calls to play_cb divided by the call duration. In some instance the time different between 2 consecutive play_cb() is over a second. The jitter buffer discards is 591 packets for an 8 second call. The thread running on_rx_rtp() is overflowing the jitter buffer because the consuming wmme thread is executing too slow. I am considering using a different timing source. ----- Original Message ---- From: Benny Prijono <bennylp@xxxxxxxxx> To: pjsip list <pjsip at lists.pjsip.org> Sent: Thu, December 17, 2009 5:09:57 AM Subject: Re: PJSIP audio problem On Tue, Dec 15, 2009 at 3:18 PM, peteryzwei <peteryzwei at yahoo.com> wrote: > Resending. > > Also saw another slow problem in wmme_dev.c stream_start(). The time difference between the calls to waveOutRestart() and waveInStart() can be as high as .89 seconds ! Most of the time, this function executes very fast but occasionally it slows down. This is consistent with the problem reported below. > waveInStart() is only called once during call setup. Are you saying that when waveInStart() slows down it affects the quality of the rest of the call? > PJSIP is reliant on windows sound API for its timing. Is there any consideration to move to another timing source ? You can, if you want to, see the FAQ http://trac.pjsip.org/repos/wiki/FAQ#tx-timing > If so, won't the windows sound API still be needed so the slow problem may still be there ? > Yes, exactly. Windows would sill give us frames in erratic timing. We just buffer that. More below. > We are testing PJSIP v1.2 in our lab and I have an audio problem where the caller?s voice quality is poor and broken up. > Most of my test calls work and sound fine. Below is the trace log file of the bad case. > > I put additional trace statements in the code in wmme_dev.c, conference.c, sound_port.c, port.c, etc to see what?s happening. > I think the problem is that the play and record events received in wmme_dev_thread() are coming in erratically. i.e. in the good case > these events come in roughly every 7ms but in the bad case, they happen much less often, i.e. 77ms. As Nanang said, this should be fine as long as the total number of frames reported by Windows matches our expectation, e.g., if we open the device @8Khz, we expect 8k worth of samples to be reported by Windows. The erratic timing would count as jitter and be handled by the jitter buffer. > I counted the number of play_cb > and rec_cb in the log file and divided those numbers by the duration of the call to get the average. I see that on_rx_rtp() is called > every 26ms so if wmme_dev_thread() is executing at a 77ms rate, then it falls behind and the jitter buffer discards increase. > The caller?s RTP packets are being thrown away hence the poor quality. > We can't use on_rx_rtp() as comparison, since it records incoming RTP thus it depends on whether VAD is enabled on remove end, and also packet loss as well. The 77ms interval looks bad. Since we're expecting frames to be at 20ms average interval, that means you're loosing about 60% audio! Either it is that bad, or there's something wrong with your calculation. I didn't check your log closely though. > This problem is not consistent so the next time I start my application, the problem goes away. > > Does anyone know why wmme signals events for play_cb and rec_cb so erratically ? It's just fact of life. :) > Is there something being done wrong ? Frankly I don't know. > Is there a fix in a later version ? > In 1.5 we increased the default WMME playback buffer to 140 ms (from 100 ms). It does help to get some stability on some systems. I see my playback gets better on both my Vista and WM6 Prof device. Also you could try with opening the sound device at 48Khz instead of the default 16Khz. This could make the device fills up its DMA buffer (or whatever it's called) and report the frames to us faster. Cheers Benny _______________________________________________ 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
