Alexander Chemeris wrote:
Hello,

On 9/8/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote:
  
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.
    
Did you rewrote mic thread too? Does this 110ms come from mic thread?
  
I rewrote the mic thread, but it had no measurable impact on the latency.  I believe it should use DirectX as well for consistency, but that is about it.


  
The code still shows the effects of about 5 changes of direction.
    
Emm.. What do you mean by "5 changes of direction"? Do not understand this.
  
I reworked my code about 5 times as I figured out more of the intricacies of DirectSound.  My only previous experience with DirectSound was writing an app to record from a USB controlled desk phone, but that was using Microsoft's managed API in .NET.

There are a number of inactive code blocks and unused variables I need to clean up.  I can send the patches as is if you are interested.

There are a number of places for additional improvement (but I doubt we will realize much more of a performance boost).  Right now I only write or read from the DirectSound buffers on frame alligned boundries.  The mic thread always pumps the most recently recorded frame into the mic queue, even if some have been missed.  The speaker queue will add data to the directx buffer, but ocassionally falls behind and has to jump to catch up.  There are definately events that happen in windows that cause the thread to block and miss some frames.  The main loop of the thread executes in far less than 1ms most of the time, but sometimes it will get blocked for 30ms at a time.  I need to start up ethereal and messure the outputs.  It seems to happen when using WaitForSingleObject or WaitforMultipleObjects which is used in the underlying message passing mechanism as well.  It is also possible that some unexpected delays could occur when accessing the SpkrQ or MicQ objects, but these are both done with NOWAIT and shouldn't ever block.

I should also move the mediathread timer into the WNT dma task instead of SpeakerThreadWntDX.cpp.  It won't make any functional difference, but it would make the distinction easier to recognize.

The delay using my new code seems to be in line with CouterPath's X-Lite phone.  I don't know much about the inner workings of their phone, but a look at the dll dependancies would indicate they do not use DirectSound, so these numbers could be reached otherwise.

Charlie


_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/

Reply via email to