Alexander Chemeris wrote:
> Hello, > > On 9/8/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote: > >> Alexander Chemeris wrote: >> 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. > > So, mic thread still use Windows Media. That is what I want to know. > How this 110ms are distributed among mic/spkr/flowgraph/etc? Did you > do particular measures? I am using DirectX for the Mic thread (I think using DirectSound one place and windows media another sounds like a bad idea. I can't back that statement up in any way, so feel free to disagree), it just didn't help in a messurable way. I am not sure how to messure the latency of each component. I am messuring the echo path as a whole by using recorders in the flow graph. It was 230ms and is now 110ms. I am opening each recording in Audacity and comparing the offset of the sound as it went to the spkrQ and the echo from the mic. I also tested with a Plantronics CS50 USB headset, and it apeared to add 40ms to the delay. I am positioning the microphone directly in front of the speakers, but at aproximately 3ms / meter I don't think that is a major source of latency. I guess I could use rdtsc or such to mark the packets as I place them in the speaker queue. If directx is correct I am getting about 35 - 45ms in the speaker driver (assuming the play cursor is acurate enough). There doesn't apear to me much delay in the mic thread. If I call my PSTN desk phone (using SIP to Asterisk and PRI to our telco) I and speek into both mics at the same time, the Softphone to PSTN connection is slightly faster than PSTN to softphone, but I believe a significant part of that could be the jitter buffer. If I call the asterisk server and put it in an echo test the delay is in the 80ms range (FromMic to ToSpkr). That would be on par with a 40ms jitter buffer at each end, but it is probably more like 20ms at asterisk and 60ms at the softphone. >> 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. > > I'm interested, but will not be able to review them before October. > I'll go on > the vacation next week. :) So feel free to post them to the tracker when > you consider them stable. > >> 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 > > Did you use rdtsc to measure such small delays? I am using the AudioBuffer. The Playposition is moving at 8 samples per ms. > How Ethereal could help you here? I was thinking I could sample the outgoing RTP packets and see if they are consitantly sent at 10ms intervals (it time stamps the capture) > >> 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. > > OsMsgQShared::recieve() and OsMsgQShared::send() should not block with > NO_WAIT > if code behave as I understand it. Do your thread runs as timecritical? Yes, it is time critical. > >> 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. > > Yes, it will be good. > >> The delay using my new code seems to be in line with CouterPath's >> X-Lite >> phone. > > Sounds inspiring.. :) > Glad to hear it. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
