On Tue, 2005-07-05 at 10:37 +0100, Giles Scott wrote:
[snip]
> Asterisk 1.0.7 running on Dual Opeteron smp Suse linux.
> Zaptel taken from CVS yesterday with USE_RTC enabled (no Zaptel hardware)
>
> With three users on a conference I see about a 1/2 second delay, it like
> having a call across a
ot;Asterisk Users Mailing List - Non-Commercial Discussion"
Sent: Monday, June 27, 2005 12:26 PM
Subject: RE: [Asterisk-Users] Re: Horrible MeetMe performance
If you have Zaptel cards, does setting the build to USE_RTC use that
timing source in preference to the Zaptel card interrupts?
If you hav
> If you have Zaptel cards, does setting the build to USE_RTC use that
> timing source in preference to the Zaptel card interrupts?
If you have a zaptel card, you shouldn't be loading ztdummy. So,
therefore, no problems!
--Rob
___
Asterisk-Users maili
> What's wrong with the standard 2.6 ztdummy?
It doesn't use RTC. I'm assuming you mean '1.0.8' as 'standard'.
> How does HEAD zaptel interact with 1.0 asterisk?
Shouldn't cause any problems.
--Rob
___
Asterisk-Users mailing list
Asterisk-Users@list
In article <[EMAIL PROTECTED]>,
Brian Capouch <[EMAIL PROTECTED]> wrote:
> Tzafrir Cohen wrote:
>
> >>
> >>This is documented at http://www.aussievoip.com.au/wiki-AMP-Zaptel
> >
> >
> > What's wrong with the standard 2.6 ztdummy?
> >
> > How does HEAD zaptel interact with 1.0 asterisk?
> >
>
In article <[EMAIL PROTECTED]>,
Tzafrir Cohen <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 11:48:00AM +1000, Rob Thomas wrote:
> > > In my experience, several seconds of delay becomes apparent over time
> > when
> > > using an internal clock source. Seems its a clocking/timer issue.
> >
>
In article <[EMAIL PROTECTED]>,
Rob Thomas <[EMAIL PROTECTED]> wrote:
> > In my experience, several seconds of delay becomes apparent over time
> when
> > using an internal clock source. Seems its a clocking/timer issue.
>
> Yes. Meetme can have horrible issues with timing. This _has_ been fixed.
On Sun, 26 Jun 2005, qrss wrote:
> It seems
> that the voip clock is slightly faster than the hardware clock that zaptel
> is timing from. The extra samples/second must be being buffered. Of
> course, this buffering would add up over time until the point that a VOIP
> sample is played back sever
Tzafrir Cohen wrote:
This is documented at http://www.aussievoip.com.au/wiki-AMP-Zaptel
What's wrong with the standard 2.6 ztdummy?
How does HEAD zaptel interact with 1.0 asterisk?
While we're at it, and I hope I haven't missed this somewhere obvious:
If you have Zaptel cards, does set
On Mon, Jun 27, 2005 at 11:48:00AM +1000, Rob Thomas wrote:
> > In my experience, several seconds of delay becomes apparent over time
> when
> > using an internal clock source. Seems its a clocking/timer issue.
>
> Yes. Meetme can have horrible issues with timing. This _has_ been fixed.
> If you
> In my experience, several seconds of delay becomes apparent over time
when
> using an internal clock source. Seems its a clocking/timer issue.
Yes. Meetme can have horrible issues with timing. This _has_ been fixed.
If you download the CVS Zaptel drivers, use a 2.6 kernel, you can use
RTC suppo
In my experience, several seconds of delay becomes apparent over time when
using an internal clock source. Seems its a clocking/timer issue.
Certainly we are dealing with clocking differences over time and unsynced
samples are being significantly buffered and then replayed later. What
are you us
@lists.digium.com
Subject: [Asterisk-Users] Re: Horrible MeetMe performance
In article
<[EMAIL PROTECTED]>,
Dan Morin <[EMAIL PROTECTED]> wrote:
> Make sure that if you're using anything other than zaptel hardware, it
> is running uLaw as the codec. Anything else will produce ever
&g
In article <[EMAIL PROTECTED]>,
Dan Morin <[EMAIL PROTECTED]> wrote:
> Make sure that if you're using anything other than zaptel hardware, it
> is running uLaw as the codec. Anything else will produce ever
> increasing delays.
Hey, now that's a snippet of information I hadn't seen before!
All my
14 matches
Mail list logo
