my new code is running at about 110ms. I dumped the whole priming the buffer concept and dynamically adjust to the delay in the DirectSound drivers.
The code still shows the effects of about 5 changes of direction. I wrote it against sipxtapi-branch, but it should drop into media update with only a few changes. ___ Sent with SnapperMail (Palm Treo) www.snappermail.com ...... Original Message ....... On Fri, 8 Sep 2006 00:58:22 +0400 "Alexander Chemeris" <[EMAIL PROTECTED]> wrote: >Hello, > >I'm sorry for this long delay.. Did you do more testing? What is the news? > >On 9/4/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: >> On that note the media thread could also be merged, but that wouldn't make >> since when adding video support... So that is a change we wouldn't make. >I do not understand this.. How video prevent us from gathering all audio IO in >one thread? I think we'll have separate graph and separate threads for video IO. > >> Now for the complication >> DX capture and playback each use a circular buffer of userdefined size. We >> can drive off of a timer, or for more acuracy request that we be notified >> via an event (wait handle) each time the buffer reaches a notification >> point. If the record and playback are using the same device one can be >> reasonably assured that these activities are synchronized. When I was >> working with echo cancelers I learned that the clocks on different devices >> will almost always have differences (speex echo cancelation will not work if >> the playback and record devices are different). I don't know what the >> typical margin of error on the typical audio clock is. >Is it hard to implement workaround for clock skew? To keep capture and playback >synchronized we could drop silent frames. There are many silence in our speech >wich could be safely removed. And dropping frames on playing should not be too >hard to implement. Or we could use soft DSPs to accelerate/slow down several >frames. What do you think about this? > >> Right now I am going to drive the media thread from a timer in the windows >> directx SpeakerThread code (the Windows multimedia timer makes this very >> easy). If this works well I assume we should use a timer from sipXportLib >> and make it a cross platform change. >I suspect portLib's timer does not have enough accuracy on the most of the >systems. We need more then 10ms accuracy, whereas usual timers provide 20ms >quantization. > > >Regards, >Alexander Chemeris. >_______________________________________________ >sip _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
