Hello, On 8/21/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: > I did on my local machine, but I am now going to move my aplication to > the sipXtapi branch so I can get major bug fixes without loosing > stability. I was using the media branch so I could implement the echo > canceler, but we don't need it any more (our headset adapters implement > it). I hope to work on these projects on my own time, but as we get > closer to a useragent that meets our needs I am expected to move on with > company time. We really appreciate time you're spending on this project. You're working with really important and complicated places.
BTW, I have a talk with Dan Petrie about echo cancelation and he said that AEC, included in mediaLib is a giood one. Did you test it? >>BTW, did you look into dedicated libraries for adaptive Jitter Buffer >>implementation? > I noticed that the speex library has one, and have considered using it, > but I haven't had the time to research it. If it weren't for the > garbled audio I wouldn't worry about it, we are using this on a LAN > where there shouldn't be much jitter. While I believe mpJitterBuffer > was causing problems on the boundry of either an empty or full audio > buffer (probably full, do to missed timer events and the Media thread > falling behind. It wasn't the spkr queue, as the distorted audio was > recorded in the 'ToSpkr' recording object.) I don't feel like I have > much of a problem with jitter itself. I think that inconsistancy of timer events is the root of many audio related problems here. Under Windows frame begin signals are generated by WOM_DONE events in speaker thread. Due to debug output this events often get delayed and then bursted out. Regards, Alexander Chemeris. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
