|
I've tried the fix,
I think it has more performance, I think that setting up a queue for three kinds of messages is not the best approach, maybe the best option is removing the queues in the Encoder and Decoder for future releases. Thanks Soledad Sorry, I'm not sure I understood you fully. Does my version works for you? I guess yes, but for sure...
What about removing queues for Encoder and Decoder - it more then just performance/latency question. It is more of design. This part of code needs some shaping I haven't done yet. Idea of input and output RTP connections should be expressed slightly diffrent in code. I'm sorry; I will explain myself a bit more.
Your fix does work for me. It has the same result than the fix I've published before. The new fix has more performance that the old one, but my fix was following the architecture principle :). When I've told you about removing the queues, I was talking about the queue that the encoder is using for handling the events: SELECT_CODECS, DESELECT_CODECS, START_TONE, STOP_TONE, etc. I can not see why decoder and encoder are using a queue of messages. Using queues decreases the performance, I understand that it is a design decision but I don't think that it worth to use queues in this case. But it is just a point of view. BTW, where can I find SipXcallLib documentation? Is there Doxygen documentation or something to make it easier to understand the modules? Thanks, Sole Well, using queues in sipXmediaLib is a performance benefit actually. :) Queues allows us to do audio frame processing without any interruption and (sic!) calls to synchronization functions. So incoming requests are processed only when inbetween frame processing. This also save us from handling crazy problems with flowgraph topology changes during audio processing. But for decoder/encoder there is a subtle difference - they're part of other resource, which actually handles queued requests. I'm not happy with this situation and hope to change it once I have spare time - no resources should contain other resources, this breaks design principle and introduce a lot of headache and problems like one we have here. As for sipXcallLib documentation - yes, there are some Doxygen-style docs in headers. But I personally have not compiled it with Doxygen for a long time - I just read it raw in sources :)
Finally fixed in rev 10632 of sipXtapi branch:
http://scm.sipfoundry.org/viewsvn/sipX?view=rev&rev=10632 Ok. Now really finally fixed.
Count rev.10638 and rev.10640 commits. |
||||||||||||||||||||||||||||||||||||||||||||
It should be better, because it avoids a one frame delay in in selectCodecs/deselectCodecs processing.