____________________________________________________________________________________

Hi all, great library! I noticed when updating today that the media lib is not working so well under OSX (at least that is the only platform I'm currently testing with). Specifically, lines 1727 of pjmedia/conference.c /* Ignore if we didn't get any frame */ if (frame_type != PJMEDIA_FRAME_TYPE_AUDIO) continue; When testing using the pjsua client, placing a call (with any codec) results in almost (it seems) every other audio frame being dropped. This results in extremely choppy playback on the pjsip client - sending audio is fine. When I comment out that line, local playback of received audio is perfect. So, it seems that a lot of frames are not marked as PJMEDIA_FRAME_TYPE_AUDIO when they should be... I tried chasing the location of the frame type setting, but I am very unfamiliar with the code base and could not decipher how the read loop was supposed to work. One thing that I noticed, that may be related, is dump stats while in call shows a lot of jitter on the received side, not sure if that is really normal. jitter : 0.000 124.270 11020.000 15.375 I can work with the older revision, but would be interested in helping to get this fixed. Thanks ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

  } else {

                                   cport->samples_per_frame);

I'm getting that as well under OS 10.4.11. It appears there was a change in 1623 that caused the problem: Index: conference.c =================================================================== --- conference.c (revision 1622) +++ conference.c (revision 1623) @@ -1269,6 +1269,9 @@ } else { + /* Initialize frame type to None */ + *type = PJMEDIA_FRAME_TYPE_NONE; + /* * If we don't have enough samples in rx_buf, read from the port * first. Remember that rx_buf may be in different clock rate! @@ -1296,6 +1299,9 @@ TRACE_((THIS_FILE, " get_frame returned non-audio")); pjmedia_zero_samples( cport->rx_buf + cport- >rx_buf_count, cport->samples_per_frame); + } else { + /* We've got at least one frame */ + *type = PJMEDIA_FRAME_TYPE_AUDIO; } cport->rx_buf_count += cport->samples_per_frame; @@ -1718,6 +1724,10 @@ /* Check that the port is not removed when we call get_frame() */ if (conf->ports[i] == NULL) continue; + + /* Ignore if we didn't get any frame */ + if (frame_type != PJMEDIA_FRAME_TYPE_AUDIO) + continue; } /* If we need to adjust the RX level from this port, adjust the level -Norman On Dec 18, 2007, at 1:11 AM, P.J. Cast. wrote: > Hi all, great library! > > I noticed when updating today that the media lib is > not working so well under OSX (at least that is the > only platform I'm currently testing with). > > Specifically, lines 1727 of pjmedia/conference.c > /* Ignore if we didn't get any frame */ > if (frame_type != PJMEDIA_FRAME_TYPE_AUDIO) > continue; > > When testing using the pjsua client, placing a call > (with any codec) results in almost (it seems) every > other audio frame being dropped. This results in > extremely choppy playback on the pjsip client - > sending audio is fine. > > When I comment out that line, local playback of > received audio is perfect. So, it seems that a lot of > frames are not marked as PJMEDIA_FRAME_TYPE_AUDIO when > they should be... I tried chasing the location of the > frame type setting, but I am very unfamiliar with the > code base and could not decipher how the read loop was > supposed to work. > > One thing that I noticed, that may be related, is dump > stats while in call shows a lot of jitter on the > received side, not sure if that is really normal. > jitter : 0.000 124.270 11020.000 15.375 > > I can work with the older revision, but would be > interested in helping to get this fixed. > > Thanks > > > > ______________________________________________________________________ > ______________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http:// > mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

  ____________________________________________________________________________________

Yes, that's exactly the change that seems to break audio. Thanks for confirming, as I was starting to think I was the only one since this change has been there for almost two weeks. I should have mentioned that I tested with both 10.4 & 10.5 and the problem is the same for both. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

P.J. Cast. wrote: > Yes, that's exactly the change that seems to break > audio. Thanks for confirming, as I was starting to > think I was the only one since this change has been > there for almost two weeks. > > I should have mentioned that I tested with both 10.4 & > 10.5 and the problem is the same for both. Sorry for the delay. You're absolutely right, this was a silly bug. I've fixed this in r1637. thanks, -benny

  ____________________________________________________________________________________

Awesome! I can confirm latest revision works goods under OSX. Thanks ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

P.J. Cast. wrote: > Awesome! > > I can confirm latest revision works goods under OSX. Cool! And thanks for confirming this! cheers, -benny > Thanks >