Lafras Henning wrote: > Hi Benny, > It is working better now, but I am getting clicks in speech due to packet > loss. This would pretty much depend on the PLC of the codec. What codec did you use? > Tests from my app and PJSUA gave the following results only > when -clock-rate=8000 > > (sip:904 at mouselike.org) > > pkt loss=39 (2.5%), > pkt loss=79 (4.6%), > pkt loss=51 (3.2%) Did you mean you didn't get packet lost with non-8Khz sampling rate? I asked you some mails ago about the type of silence frames that you received. I just found out yesterday that some endpoints send RTP packet with no payload (see http://www.pjsip.org/trac/ticket/388), and I'm still not sure what would happen in the jitter buffer when stream.c receives these packets. Maybe it will treat these as missing packets thus causing it to trigger the PLC. > CPU use remains low (<2%) but it seems as though re-sample may be affecting > the thread receiving the packet. No, it won't. Incoming (rtp) packets are handled by separate thread (the worker threads in pjmedia_endpt), and not by the media flow thread (which belongs to sound device, normally). > Do you think the performance would be better if the conference bridge > remained at 16khz and the port does the re-sampling? I'm not sure about it. The best configuration would be if you run the bridge at the same clock rate as the codec. > B.T.W. >> Frankly this could be a bug (see below). But even if frame.type is >> NONE, the frame.size would (normally!) be zero too, so it's not a >> major bug. > > In my port I found frame.size to be 320 even when frame.type is NONE. Yeah, it's the bridge who's done this. If you connect your port to some other port (like, stream, for example) directly, frame.size would normally be set to zero. regards, -benny
