On 2/8/08, Anshuman S. Rawat <arawat at 3clogic.com> wrote: > Hi, > > We have integrated G729 codec with PJSIP 0.7.0 (revision 1538) and media > flow works fine for 1 call at a time. However, if we make multiple (even 2) > G729 calls in parallel the media becomes very choppy and choppiness seems to > increase with increasing number of parallel G729 calls. The root cause of > the problem seems to be the fact that encoding and decoding happen in a > single thread for all the calls (I printed out thread IDs in the encode and > decode routine of G729 - thread ID was same). The small verification I did > was that I placed 2 parallel (G729) calls and heard choppy media. On plaving > of the calls on hold the choppiness dissappeared and reappeared when the > held call was unheld. > When conference bridge is used, then most media processing will be done in the context of the sound device thread indeed, because audio sources need to be mixed at the same time. Are you really tight on CPU? If so, then perhaps this was caused by the lack of power to run more than one simultaneous G729 calls rather than encode/decode being done in a single thread. > I tried increasing the number of worker threads being created in endpoint.c > to no effect. I was contemplating of how to put encode and decode in > seperate threads. Maybe Benny or someone whose faced a similar problem could > give some suggestions? > You can create a media port with a worker thread in it, so that: - when get_frame() is called on this port, you call get_frame() to the stream. - when put_frame() is called, you copy the frame and instruct the worker thread to call put_frame() to the stream. Then instead of registering the stream to the bridge, you register this port to the bridge instead. cheers, -benny > Thanks, > Anshuman
