ant-phone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ant-phone-devel] Latency, fragments and their sizes.


From: Roland Stigge
Subject: Re: [Ant-phone-devel] Latency, fragments and their sizes.
Date: Wed, 25 Feb 2004 13:38:41 +0100

Hi,

On Sat, 2004-02-14 at 18:59, Bruno Hertz wrote:
> > This is also a known problem. We will need a better dynamic speed drift
> > compensation. The ISDN and dsp devices don't run in sync.
> 
> How exactly can they run out of sync?

The devices themselves run on their own clocks. E.g. both say that they
run at 8000Hz, but in reality, the DSP may be 7999Hz and the ISDN card
8001Hz. After some time we get in trouble. While the one direction fills
up a buffer (and creates a delay), in the other direction the
destination isn't feeded fast enough and the device plays back an
undefined fragment. The latter is the case for DSPs and I guess it's the
same for ISDN.

> where ant in both cases does simple read and writes as much real
> time as possible. I.e. in case there is no extensive buffering in
> either the isdn or sound drivers (and ant, of course) my understanding
> is there should be only millisecs delay from voice to isdn and from
> isdn to line out, at least in an ideal world :) Or in other words,
> the dsp is just a 'push through' device with drivers (hopefully)
> optimized, besides other things, for minimum latency. This may be
> a pretty basic question, but I really don't see the point to hook in
> for a possible drift compensation.

This is right for the optimum case. People often say it's crazy to try
to run differently clocked devices in sync. But theoretically it's
possible e.g. with cheating in (or out) an additional sample from time
to time for destination devices running slightly to fast (or slow).

> One further question: could the call distance have an impact on
> those delays?

Only in the order of magnitude you recognize it with traditional
(hardware) telephones.

> So if you too did
> observe varying behaviour depending on call distance, maybe you have
> an idea what the reason might be?

No. But maybe someone else?

> And a last question: did you already test ant on a preemptible patched
> kernel? If so, did it make any difference?

Unfortunately, no. I still have to figure out how to run /dev/ttyI with
my 2.6.2 kernel. Maybe we just have to go for CAPI support to be on the
safe side.

> Btw in case you consider my questions too 'newbie' I'd appreciate
> pointers to isdn/sound documentation which might help me improving
> my understanding and level of discussion.

Just read the documentation about OSS[1], ALSA[2] (planned support),
ttyI*[3] and CAPI (planned).

bye,
  Roland

[1] http://www.opensound.com/pguide/oss.pdf
[2] http://www.alsa-project.org/
[3] isdn_audio(4), ttyI(4)

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]