Revision: 1623 Breaks OSX Media

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

 



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 at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20071218/7a5d4b62/attachment-0001.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux