On 9/9/06, Charlie Hedlin <[EMAIL PROTECTED]> wrote:
> Alexander Chemeris wrote:
>> 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.
Ahh. Sorry, misunderstand you. Mixing Windows Media and DirectSound
should be fine, except we want to do AEC. But, sure, it is much better to use
one or other, not both.

> I am not sure how to messure the latency of each component.
As in the picture, I've send earlier:
1) ToSpkr -> SpkrThread
      delay = number messages in queue * 10ms
    It is variable..
2) SpkrThread -> speaker
      delay is inside the driver.
    You say it is ~40ms
3) speaker -> mic
      3ms/m - we could assume it equal to zero.
4) mic -> MicThread
      delay is inside the driver.
    Lets consider ~20ms..
5) MicThread -> FromMic
      delay = number messages in queue * 10ms
    It's variable too.

So for mic and spkr queues we have (110ms - 40ms - 20ms = 50ms) or 5 frames.
Not ideal, but very good already. :)

BTW, number of messages in the queue could be retrieved by
OsMsgQShared::numMsgs(), but it is blocking opereation! Check if it is
used inside
your media thread.

> 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.
Non-trivial..

> 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.
Yes, it should add some delay.

> 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.
As I know, Asterisk does not use jitter buffer for echo test. It just mirror
all incoming RTP to the sender.So we could assume almost all of this delay
is inside sipXtapi. In this audio loop:
FromMic -> ToNet -> net -> Asterisk -> net -> FromNet -> ToSpkr
We may have following sources of delay:
1) Network driver
2) Asterisk echo test
3) sipXtapi jitter buffer

I think 3 is the most of the delay, but 1 and 2 may add to it too.

> > 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)
Ya. Already thought about this.
But keep in mind, that flowgraph is executed in other thread, then media tasks.
And begin frame is signaled by message.


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

Reply via email to