search for: jb_put

...ome that I have enabled jitter buffer in the SIP channel by setting sip.conf parameters jenable=yes, jbforce=yes, jbmaxsize=200 and jbimpl=fixed. However on setting these parameters I am unable to hear on the trunk side. From the jitter logs as given below, I can see audio frames being dropped: JB_PUT {now=1130}: Dropped frame with ts=21125 and len=20 JB_GET {now=1130}: now < next=2121 JB_GET {now=1142}: now < next=2121 JB_GET {now=1163}: now < next=2121 JB_PUT {now=1181}: Dropped frame with ts=21132 and len=20 JB_GET {now=1181}: now...

> Yes. Jean-Marc has made the API more similar. > > Jean-Marc: Have you looked at the API we have for the > asterisk/iaxclient jitterbuffer? Just did. > It's pretty close to what you have now -- the major difference is that > your jb still assumes it can "own" the data passed in -- it copies it, > and it destroys it at will. With the API I put together,

...h?view=markup&rev=470 > > A couple things I don't understand. Why do you need both the local > clock > and the remote clock and how do you define those anyway? There's the "timestamp", which the remote side puts on frames, and the local time, which is used for jb_put and jb_get. They're defined in milliseconds. > BTW, does your > jitter buffer consider that there can be overlaps or holes between > frames, especially if using PCM? There shouldn't be overlaps, but I think it currently deals with some types of messy timestamps that are, fo...

...> > A couple things I don't understand. Why do you need both the local > > clock > > and the remote clock and how do you define those anyway? > > There's the "timestamp", which the remote side puts on frames, and > the local time, which is used for jb_put and jb_get. They're defined > in milliseconds. I think this is equivalent to what I'm doing with jitter_buffer_tick(), except that my approach doesn't require explicit knowledge of the local time (I don't care what the local time is, just how it's incremented). Also, I th...

> Perhaps, but then you need to assume that the jitterbuffer can just > throw away the data, and that limits how you can use it. In object- > oriented terms, you might want to pass objects to the JB, and then > call a destructor on them. In C terms, you may want to allocate > frames via malloc(), and then call free() on them later. You might > want to pass in

...couple things I don't understand. Why do you need both the local >>> clock >>> and the remote clock and how do you define those anyway? >> >> There's the "timestamp", which the remote side puts on frames, and >> the local time, which is used for jb_put and jb_get. They're defined >> in milliseconds. > > I think this is equivalent to what I'm doing with jitter_buffer_tick > (), > except that my approach doesn't require explicit knowledge of the > local > time (I don't care what the local time is, just ho...

...the > frames down before sending them? Sounds complicated and even > technically > impossible for the general case (what if the frames *can't* be broken > down for a particular codec?). Again, I don't think the API prohibits the use that you've described. You can call jb_put() with that overlapping data. My _implementation_ may not like it, but the API can support it. > >>> Well, that API clearly has limitations that mean I can't use them >>> to do >>> what I need. Unless you're willing to change that (and even then >>&gt...