I have had somewhat frequent problems with garbled audio after a call has been established a certain duration. After much tracing and debuging I determined it had to be coming from either MprDeJitter or MpJitterBuffer. I posted about this and opened tracker issue XMR-69 with patches (which I said myself added more bugs than they solved). I have stamped out the garbled audio issue on my test user base with a variation on the patch, but I now crash the media thread every now and then (I have 8 users running the app for 8 hours a day, and get about 1 failure per day over several weeks).
My aproach has been to move more of the Dejitter processes into MprDeJitter and let MpJitterBuffer do less of the work. One place has sequenced RTP packets, the other has audio data, so it seemed the right thing to do. Since I haven't wanted to take the time to make the jitter buffer adaptive, I used MIN_RTP_PACKETS to determine how much preloading to do. There seemed to be a bunch of inactive code in this area, and I connected and added to it with good results. Now I find that this functionality is being depricated. It seems like the depricated code would be used even if I were doing this in an adaptive manner, so I wanted to know if someone else was taking a different aproach to this issue, or do I just need to hurry up and get my patches cleaned up and to the standards so they can be allowed in and head off the deprication? Thank you, Charlie Hedlin _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
