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. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
