Hi, AFAIK, inconsistent intervals in play_cb and rec_cb events seem to be common case, we used to call this audio device burst. As long as the average of the intervals is equal to ptime (in other word, the clock rate is not 'broken') it shouldn't cause problem, as it should have been handled/tolerated, locally by delay buffer and remotely by jitter buffer. However, when the clock rate is broken, it will cause audio impairment indeed, AFAIK, this usually happens on CPU spikes or high-CPU loads. IIRC, it also sometime happens after resuming from debugging break, not really sure why though (the WMME tries to catch up the underflows?). Not really sure about high interval between waveOutRestart() and waveInStart(), CPU load/spike again? :) Regarding another timing source, please see [1]. Let's wait for other feedbacks :) --- [1] http://trac.pjsip.org/repos/wiki/FAQ#tx-timing --- BR, nanang On Tue, Dec 15, 2009 at 10: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. > > PJSIP is reliant on windows sound API for its timing. Is there any consideration to move to another timing source ? If so, won't the windows sound API still be needed so the slow problem may still be there ? > > > > > ----- Original Message ---- > From: peteryzwei <peteryzwei@xxxxxxxxx> > To: pjsip at lists.pjsip.org > Sent: Tue, November 24, 2009 12:26:15 PM > Subject: PJSIP audio problem > > Hello, > ?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. ?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. > > 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 ? > Is there something being done wrong ? > Is there a fix in a later version ? > > Any feedback is appreciated. > > Peter > [ .. cut ..]
