|
The pro would be one less thread to synchronize. At first glance there
seems to be no reason we couldn't play a frame and imediately record a
frame before waiting for the next timer tick (whatever is driving it).
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. 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. It is probably possible to adjust for a slight variation in the code that reads and writes the buffers. This may be desirable as it will allow us to keep the mic and spkr delays somewhat fixed. If the mic clock or the spkr clock are slightly missaligned and the latency slowly grows or shrinks over a long call we could have a problem. It the mic samples at 7999 hz and the spkr plays at 8001 hz and the timer driving the media thread is perfect the playback latency is going to grow one frame every 80 seconds, and our from mic queue will fall one frame behind every 80 seconds. If a call is 2 hours long, that is a lot of missed sends (10ms of silence or concealment depending on the end point) and the playback latency is going to be 900ms larger than when started, or we will have droped up to 90 frames do to a full spkr queue. If we are on Windows XP we can use FullDuplex devices and use certain full duplex filters (echo cancelation is one of them) that may even use hardware. Unfortunately the code would have to detect the OS and fall back to opening seperate capture and record buffers. I don't think full duplex devices usefull enough to implement. 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. Charlie Alexander Chemeris wrote: Hello, On 9/4/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: |
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
