iaxclient-devel — Development Discussion List

Re: [Iaxclient-devel] codec support

[Steve K. <st...@st...>]

Dima wrote:

>On Monday 01 March 2004 17:01, Steven Sokol wrote:
>  
>
>>>I'm new to this list. Can somebody update me with info: is any work
>>>done for supporting codec other them GSM. I'm interesting on adding iLBC
>>>      
>>>
>>codec.
>>
>>We've talked about adding support for iLBC, SpeeX and possibly LPC-10.  We
>>also need to put in support for the wasteful but ubiquitous G.711 a/u.
>>Before we do that, we need to work out:
>>
>>1.  A modular framework for adding codecs to iaxClient
>>2.  How to negotiate codecs over IAX2
>>3.  Which codecs we want and in what order
>>
>>Can everybody vote for their favorite codecs?  Here's my list in order of
>>preference:
>>
>>1.  g711 a/u  - Makes us compatible with nearly everything
>>2.  iLBC      - Integrates us with Firefly network, plus others.
>>3.  SpeeX     - Low bandwidth, free, unencumbered
>>4.  ADPCM/G.723	- NOT G.723.1 (patented) but the old, free version
>>5.  G.726/32	- The new codec added by Mark to Asterisk
>>6.  LPC-10		- Because it was there...
>>
>>    
>>
>for now I'm interested in freeware codecs only: iLBC then g711 then speex.
>
>Checking TODO and sources I see mentioning of 20ms frame size used with GSM. 
>Can anybody comment this issue for iLBC codec or may be point to some 
>materials.
>  
>

I'd just look at asterisk's implementation for ideas [although not code, 
because asterisk is GPL].

The 20ms frame size vs 30ms preferred frame size for iLBC will be an 
issue that needs to be dealt with when you make codecs modularized.  
Personally, I'd say that one should start with G711a/u, because the 
implementation of that will be about 50 lines of C code for coding and 
decoding (maybe less), and the bulk of the work will be in just 
modularization.   To be sure you get the modularization right, make G711 
work with 20ms or 30ms frame sizes.  Then once that's working (and you 
haven't broken GSM, because you'll need to modularize that as well), 
adding any of the other codecs will be just a matter of the proper 
cross-platform Makefile-fu plus a small amount of glue code, and you'll 
have two examples of how to do the glue code.

An experienced programmer should be able to do this (G711, GSM, iLBC) in 
somewhere like 5 - 20 hours or so. 

Re: [Iaxclient-devel] codec support

[Dima <le...@uk...>]

On Monday 01 March 2004 17:01, Steven Sokol wrote:
> > I'm new to this list. Can somebody update me with info: is any work
> > done for supporting codec other them GSM. I'm interesting on adding iLBC
>
> codec.
>
> We've talked about adding support for iLBC, SpeeX and possibly LPC-10.  We
> also need to put in support for the wasteful but ubiquitous G.711 a/u.
> Before we do that, we need to work out:
>
> 1.  A modular framework for adding codecs to iaxClient
> 2.  How to negotiate codecs over IAX2
> 3.  Which codecs we want and in what order
>
> Can everybody vote for their favorite codecs?  Here's my list in order of
> preference:
>
> 1.  g711 a/u  - Makes us compatible with nearly everything
> 2.  iLBC      - Integrates us with Firefly network, plus others.
> 3.  SpeeX     - Low bandwidth, free, unencumbered
> 4.  ADPCM/G.723	- NOT G.723.1 (patented) but the old, free version
> 5.  G.726/32	- The new codec added by Mark to Asterisk
> 6.  LPC-10		- Because it was there...
> 
for now I'm interested in freeware codecs only: iLBC then g711 then speex.

Checking TODO and sources I see mentioning of 20ms frame size used with GSM. 
Can anybody comment this issue for iLBC codec or may be point to some 
materials.

Thanks,
Dmitry

> We may also want to consider creating a plug-in module to add G.729-C (the
> pseudo-free version of G.729 for non-commercial use).  We need to read the
> license very carefully and perhaps it would require the end user to compile
> their own .so/.dll to make use of this.
>
> I wonder if there is a way to create a commercial G.729 plug-in that can be
> sold via Digium?  If we have a common codec interface that is common across
> all clients, couldn't we create a standard binary dynamic link format for
> each platform (x-nix, Windows, Mac) and ask Digium to sell the plug-ins?
>
> In any case, yes, I would love to see multiple codecs supported.  But
> before we rush in, we need to agree on a modular format that, hopefully,
> can be used to support _any_ codec.
>
> Steve
>
> Steven Sokol
> Owner/Manager
> Sokol & Associates, LLC
>
> Phone:  816.822.1807
> IaxTel: 700.613.9004
> Web:    http://www.sokol-associates.com
>
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel

Re: [Iaxclient-devel] codec support

[Adam H. <ad...@te...>]

Mark Spencer wrote:

>>2.  How to negotiate codecs over IAX2
>>    
>>
>
>This part I can actually comment on.  Whereas SDP based systems list
>codecs in the order desired, IAX2 has a simpler (but arguably less
>flexible) system for doing the codec negotiation, which is that the caller
>specifies two things -- a preferred format and a mask of its capability.
>Then the server being called responds back with a specific format it
>wishes to use.  In principle, you can switch codecs to anything that is
>within the end device's capability.
>
>  
>
People may want to look at my mod to libiax2 (firefly's version), I've 
seperated preferred format and the mask into two params in iax_call

>>I wonder if there is a way to create a commercial G.729 plug-in that can be
>>sold via Digium?  If we have a common codec interface that is common across
>>all clients, couldn't we create a standard binary dynamic link format for
>>each platform (x-nix, Windows, Mac) and ask Digium to sell the plug-ins?
>>    
>>
>
>We could look at this as a possibility, but I need to find a new G.729
>provider first, as Voiceage's code is basically crap (in particular their
>brain-dead copy protection), and they are absolutely most miserable,
>untrustworthy, and irresponsible company i've ever had to deal with, so
>the last thing I want to do is create another product involving them.
>
>  
>
I've created a g729 plugin for firefly but licensing it from sipro is 
yet to come :|  Voiceage = sipro so sounds like I'm in for some fun. 
When we license it, I'm happy for us to sell it as a plugin (ie dll) and 
you could use it with iaxcomm. I'd have to implement some kind of 
security sheme (I assume?) but it should be a simple http request and reply.

thoughts?

-Adam

Re: [Iaxclient-devel] iaxc_shutdown MUTEX deadlock

[Steve K. <st...@st...>]

S wrote:

> Hi Steve,
>
> I become aware you are the iaxclient project admin.

That would be me :)

> 1) question
>
> Maybe you are versed with th iaxclient_lib.c code and I like to ask 
> direct a question about the "int service_audio()" function.
> This code is in service_audio :
> for(;;)
> {
>    toRead = 160;
>    if ( audio.input(&audio,buf,&toRead))
>    {
>       iaxc_usermsg(IAXC_ERROR, "ERROR reading audio\n");
>       break;
>    }
>    if ( ! toRead)
>           break;  /* frame not available */
>    /* currently, pa will always give us 0 or what we asked
>     * for samples */
>     else
>     send_encoded_audio( &calls[selected_call], buf, iEncodeType);
> }

That's not what should happen :)

What are you using to build?  Are you using the audio_portaudio stuff, 
or are you trying to make the old (not maintained) windows stuff work?

If you're using portaudio, then audio.input should be pa_input, which is 
a simple function, which just looks to see if the RingBuffer has data in 
it.  Unless something is causing things to run very slowly for you, then 
it should only have data occasionally.


> My IAX client didn't get out of the "for" loop, because there is every 
> time data on the input channel.

> For this reason my iaxc_processor thread hang in the service_audio 
> function and is not able to do other work (iaxc_service_network, 
> iaxc_do_pings....).
> If I remove the endless "for" loop out of service_audio my client is 
> able to work.


But that could cause you to get behind and lose audio.  If the 
service_audio function is called more than once every 20ms, it should be 
OK, though.

> I didn't understand why I am the only one who run into this endless 
> loop ?
> Any comment's what I have done wrong ?

I don't know what went wrong for you; I guess you'll need to tell us 
more about what you have done.



> 2) question
>
> A other question I have is about CVS in this project.
> Why are no CVS tags in the source files ($Revision: $ ,$Author: $, 
> $Log: $) this help for a better overview.

No particular reason.  Obviously, that wouldn't be hard to do.  It does 
make merging in other CVS repositiories a pain, though.  (I deal with a 
bunch of CVS repositories [at least iaxclient sourceforge CVS, libiax2 
CVS, portaudio CVS, and, I have another CVS repository of iaxclient for 
my own client] and when the code has that stuff in it, it makes all the 
files show diffs).

> A big question about the IAX2 protocol will be send later. ;-))


We'll try to answer!

-SteveK

> PS : The number of Steve's in a project should be a
>      number between 1 and 42


Actually, if you read back, the proposal is to just call any non-Steve 
contributors Steve in order to reduce confusion :)

-SteveK


>
> S wrote:
>
> > Hi All,
> >
> > in the iaxclient_lib.c the function void iaxc_shutdown() has
> a MUTEX
> > deadlock.
> > In the function iaxc_shutdown() is a call to
> iaxc_dump_all_calls()
> > which also try to get the MUTEX iaxc_lock.
> >
> > Dead lock code :
> > void iaxc_shutdown(){
> >      MUTEXLOCK(&iaxc_lock);
> >      iaxc_dump_all_calls();
> >
> >      audio.destroy(&audio);
> >
> >      MUTEXUNLOCK(&iaxc_lock);
> >      MUTEXDESTROY(&iaxc_lock);
> > }
> >
> > FIX : No Dead lock :
> >
> > void iaxc_shutdown()
> > {
> >      iaxc_dump_all_calls();
> >
> >      MUTEXLOCK(&iaxc_lock);
> >
> >      audio.destroy(&audio);
> >
> >      MUTEXUNLOCK(&iaxc_lock);
> >      MUTEXDESTROY(&iaxc_lock);
> > }
> >
> > Regard's
> >
> >   Stephan
>
> Thanks, Stephan.
>
> That's a good change, although I think there may be other bugs in
> iaxc_shutdown.  (I don't think most clients are using it right now?).
>
> -SteveK
>
> P.S.  I guess that adds to the number of Steve's in the project again, 
> eh?
>
>
>

Re: [Iaxclient-devel] iaxc_shutdown MUTEX deadlock

[S <s...@ka...>]

Hi Steve,

I become aware you are the iaxclient project admin.

1) question

Maybe you are versed with th iaxclient_lib.c code and I like to ask 
direct a question about the "int service_audio()" function.
This code is in service_audio :
for(;;)
{
    toRead = 160;
    if ( audio.input(&audio,buf,&toRead))
    {
       iaxc_usermsg(IAXC_ERROR, "ERROR reading audio\n");
       break;
    }
    if ( ! toRead)
           break;  /* frame not available */
    /* currently, pa will always give us 0 or what we asked
     * for samples */
     else
     send_encoded_audio( &calls[selected_call], buf, iEncodeType);
}

My IAX client didn't get out of the "for" loop, because there is every 
time data on the input channel.
For this reason my iaxc_processor thread hang in the service_audio 
function and is not able to do other work (iaxc_service_network, 
iaxc_do_pings....).
If I remove the endless "for" loop out of service_audio my client is 
able to work.
I didn't understand why I am the only one who run into this endless loop ?
Any comment's what I have done wrong ?

------------------------------------------------------------

2) question

A other question I have is about CVS in this project.
Why are no CVS tags in the source files ($Revision: $ ,$Author: $, $Log: 
$) this help for a better overview.

A big question about the IAX2 protocol will be send later. ;-))

Regards

   Stephan

PS : The number of Steve's in a project should be a
      number between 1 and 42

S wrote:

 > Hi All,
 >
 > in the iaxclient_lib.c the function void iaxc_shutdown() has
a MUTEX
 > deadlock.
 > In the function iaxc_shutdown() is a call to
iaxc_dump_all_calls()
 > which also try to get the MUTEX iaxc_lock.
 >
 > Dead lock code :
 > void iaxc_shutdown(){
 >      MUTEXLOCK(&iaxc_lock);
 >      iaxc_dump_all_calls();
 >
 >      audio.destroy(&audio);
 >
 >      MUTEXUNLOCK(&iaxc_lock);
 >      MUTEXDESTROY(&iaxc_lock);
 > }
 >
 > FIX : No Dead lock :
 >
 > void iaxc_shutdown()
 > {
 >      iaxc_dump_all_calls();
 >
 >      MUTEXLOCK(&iaxc_lock);
 >
 >      audio.destroy(&audio);
 >
 >      MUTEXUNLOCK(&iaxc_lock);
 >      MUTEXDESTROY(&iaxc_lock);
 > }
 >
 > Regard's
 >
 >   Stephan

Thanks, Stephan.

That's a good change, although I think there may be other bugs in
iaxc_shutdown.  (I don't think most clients are using it right now?).

-SteveK

P.S.  I guess that adds to the number of Steve's in the project again, eh?

Re: [Iaxclient-devel] iaxc_shutdown MUTEX deadlock

[Steve K. <st...@st...>]

S wrote:

> Hi All,
>
> in the iaxclient_lib.c the function void iaxc_shutdown() has a MUTEX
> deadlock.
> In the function iaxc_shutdown() is a call to iaxc_dump_all_calls() 
> which also try to get the MUTEX iaxc_lock.
>
> Dead lock code :
> void iaxc_shutdown(){
>      MUTEXLOCK(&iaxc_lock);
>      iaxc_dump_all_calls();
>
>      audio.destroy(&audio);
>
>      MUTEXUNLOCK(&iaxc_lock);
>      MUTEXDESTROY(&iaxc_lock);
> }
>
> FIX : No Dead lock :
>
> void iaxc_shutdown()
> {
>      iaxc_dump_all_calls();
>
>      MUTEXLOCK(&iaxc_lock);
>
>      audio.destroy(&audio);
>
>      MUTEXUNLOCK(&iaxc_lock);
>      MUTEXDESTROY(&iaxc_lock);
> }
>
> Regard's
>
>   Stephan

Thanks, Stephan.

That's a good change, although I think there may be other bugs in 
iaxc_shutdown.  (I don't think most clients are using it right now?).

-SteveK

P.S.  I guess that adds to the number of Steve's in the project again, eh?

[Iaxclient-devel] iaxc_shutdown MUTEX deadlock

[S <s...@ka...>]

Hi All,

in the iaxclient_lib.c the function void iaxc_shutdown() has a MUTEX
deadlock.
In the function iaxc_shutdown() is a call to iaxc_dump_all_calls() which 
also try to get the MUTEX iaxc_lock.

Dead lock code :
void iaxc_shutdown(){
      MUTEXLOCK(&iaxc_lock);
      iaxc_dump_all_calls();

      audio.destroy(&audio);

      MUTEXUNLOCK(&iaxc_lock);
      MUTEXDESTROY(&iaxc_lock);
}

FIX : No Dead lock :

void iaxc_shutdown()
{
      iaxc_dump_all_calls();

      MUTEXLOCK(&iaxc_lock);

      audio.destroy(&audio);

      MUTEXUNLOCK(&iaxc_lock);
      MUTEXDESTROY(&iaxc_lock);
}

Regard's

   Stephan

RE: [Iaxclient-devel] codec support

[Mark S. <mar...@di...>]

> 2.  How to negotiate codecs over IAX2

This part I can actually comment on.  Whereas SDP based systems list
codecs in the order desired, IAX2 has a simpler (but arguably less
flexible) system for doing the codec negotiation, which is that the caller
specifies two things -- a preferred format and a mask of its capability.
Then the server being called responds back with a specific format it
wishes to use.  In principle, you can switch codecs to anything that is
within the end device's capability.

> I wonder if there is a way to create a commercial G.729 plug-in that can be
> sold via Digium?  If we have a common codec interface that is common across
> all clients, couldn't we create a standard binary dynamic link format for
> each platform (x-nix, Windows, Mac) and ask Digium to sell the plug-ins?

We could look at this as a possibility, but I need to find a new G.729
provider first, as Voiceage's code is basically crap (in particular their
brain-dead copy protection), and they are absolutely most miserable,
untrustworthy, and irresponsible company i've ever had to deal with, so
the last thing I want to do is create another product involving them.

Mark

RE: [Iaxclient-devel] codec support

[Steven S. <ss...@so...>]

> I'm new to this list. Can somebody update me with info: is any work 
> done for supporting codec other them GSM. I'm interesting on adding iLBC
codec.

We've talked about adding support for iLBC, SpeeX and possibly LPC-10.  We
also need to put in support for the wasteful but ubiquitous G.711 a/u.
Before we do that, we need to work out:

1.  A modular framework for adding codecs to iaxClient
2.  How to negotiate codecs over IAX2
3.  Which codecs we want and in what order

Can everybody vote for their favorite codecs?  Here's my list in order of
preference:

1.  g711 a/u  - Makes us compatible with nearly everything
2.  iLBC      - Integrates us with Firefly network, plus others.
3.  SpeeX     - Low bandwidth, free, unencumbered
4.  ADPCM/G.723	- NOT G.723.1 (patented) but the old, free version
5.  G.726/32	- The new codec added by Mark to Asterisk
6.  LPC-10		- Because it was there...

We may also want to consider creating a plug-in module to add G.729-C (the
pseudo-free version of G.729 for non-commercial use).  We need to read the
license very carefully and perhaps it would require the end user to compile
their own .so/.dll to make use of this.

I wonder if there is a way to create a commercial G.729 plug-in that can be
sold via Digium?  If we have a common codec interface that is common across
all clients, couldn't we create a standard binary dynamic link format for
each platform (x-nix, Windows, Mac) and ask Digium to sell the plug-ins?

In any case, yes, I would love to see multiple codecs supported.  But before
we rush in, we need to agree on a modular format that, hopefully, can be
used to support _any_ codec.

Steve

Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com

Re: [Iaxclient-devel] codec support

[Steve K. <st...@st...>]

Nobody has done this yet..


Dmitry Mishchenko wrote:

>Hello,
>I'm new to this list. Can somebody update me with info: is any work done for 
>supporting codec other them GSM. I'm interesting on adding iLBC codec.
>  
>

[Iaxclient-devel] codec support

[Dmitry M. <ar...@od...>]

Hello,
I'm new to this list. Can somebody update me with info: is any work done for 
supporting codec other them GSM. I'm interesting on adding iLBC codec.

Dmitry

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steve K. <st...@st...>]

Steven Sokol wrote:

> One thing I have noticed, is that the audio latency under Firefly 
> seems to have much lower than the latency from iaxClient-based UAs.  I 
> would guess that Adam saved a /bunch/ of CPU cycles by talking 
> directly to the MME interface, rather than using PortAudio or some 
> other abstraction layer.  The difference is notable. (Both clients 
> were using GSM).
>
PortAudio shouldn't intrinsically add a lot of latency, but there are 
two places in the implementation that add latency:

1) I'm currently using small ringbuffers in-between portaudio and the 
library.  This was mainly to simplify the implementation, where I didn't 
need to worry about re-entrancy in the library code itself.  This 
shouldn't really add a lot of latency.

2) PortAudio's implementation itself does add a significant amount of 
latency.  You can adjust this with an environment variable, or, if you 
want, you can change where the default is set in the portaudio code.  
See this message to the list for details:

http://sourceforge.net/mailarchive/message.php?msg_id=5248539

As it says there, they chose that variable to have reliable performance 
on Windows.  Perhaps in our usage, the balance of low latency vs. never 
missing a frame is different, and we can change this.

The latency there is something like 400ms on WinNT-based systems.  The 
ringbuffers probably add only abpout 20-40ms most of the time.

> I don't know how hard it would be to go back to the native audio I/O 
> interface, but that may be one way to cut down on the audio glitches.
>
As far as glitches, I think we've found that bug, and I will post it to 
CVS as soon as we get a little more testing.  If people are impatient, 
the proposed fix can be made by commenting line 666 (ironic, eh) in 
lib/portaudio/pa_win_wmme/pa_win_wmme.c.  Obviously, doing it right 
means negating the test and removing that block, etc.  But, we're going 
to discuss it with the portaudio developers to make sure it's correct, 
and contribute it back.

    662         if( stream->past_NumOutputChannels > 0 )
    663         {
    664             if((wmmeStreamData->outputBuffers[ 
wmmeStreamData->currentOutputBuffer ].dwFl        ags & WHDR_DONE) == 0)
    665             {
    666                 break;  /* If none empty then bail and try again 
later. */
    667             }

> BTW - What are your thoughts on implementing iLBC, SpeeX, G.711 A & U, 
> and possibly the new G.726/32 that just went into Asterisk?  I know 
> you are looking to get the library clean before we add too much more.  
> Just looking for thoughts as to the difficulty.
>

Right now, we're doing testing with what we have.  Those things 
shouldn't be terribly difficult to do.   First, though, we need to make 
an abstraction for codecs, similar to how we've abstracted audio 
drivers.  Once the abstraction is made, the individual codecs shouldn't 
be difficult.  (assuming, of course, they all build cross-platform).  
That means G.711 codecs are a no-brainer; SpeeX should work easy.  iLBC 
_probably_ is portable, but I haven't checked.  I'm not familiar with 
the other codecs you've mentioned, but if the abstraction is there, it 
should be possible to add them.

Just to ensure people that development here has an exciting future; the 
next _big_ thing we want to add is video support.   The hardest part 
there seems to be a portable video capture system, and a portable way to 
display video.  Unfortunately there's no "portvideo" project out there 
that I could find.    I'm not actually sure if I'll end up putting the 
audio and/or video capture/display stuff into the library proper, 
because it might make it more difficult to integrate with applications.

If people have thoughts or ideas on that, it would be great to discuss them.

-SteveK

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Adam H. <ad...@te...>]

----- Original Message ----- 
From: Steven Sokol
>One thing I have noticed, is that the audio latency under Firefly seems to
have much lower than the latency from iaxClient-based >UAs.  I would guess
that Adam saved a bunch of CPU cycles by talking directly to the MME
interface, rather than using >PortAudio or some other abstraction layer.
The difference is notable. (Both clients were using GSM).

I'm just using window's MM interface (eg waveout). I've actually implemented
code that talks directly to the kernel but there's some bug I haven't found
which stops me from having it in firefly for the moment. You should hear it,
it lowers the latency on echo test by about 80ms.

FYI, firefly uses it's own jitter buffer. I wrote it and it was a painful
process. The main reason is to allow for sip which is coming very soon. I'll
add speex if anyone wants, unforunately asterisk is hardcoded to a certain
setting of speex though.

RE: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steven S. <ss...@so...>]

One thing I have noticed, is that the audio latency under Firefly seems to
have much lower than the latency from iaxClient-based UAs.  I would guess
that Adam saved a bunch of CPU cycles by talking directly to the MME
interface, rather than using PortAudio or some other abstraction layer.  The
difference is notable. (Both clients were using GSM).
 
I don't know how hard it would be to go back to the native audio I/O
interface, but that may be one way to cut down on the audio glitches.
 
BTW - What are your thoughts on implementing iLBC, SpeeX, G.711 A & U, and
possibly the new G.726/32 that just went into Asterisk?  I know you are
looking to get the library clean before we add too much more.  Just looking
for thoughts as to the difficulty.
 
Regards,
 
Steve 
Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com
  _____  

From: Steve Kann [mailto:st...@st...] 
Sent: Thursday, February 26, 2004 11:30 AM
To: Steven Sokol
Subject: Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?
 
Steven Sokol wrote: 
[These issues seem to affect Win32 only at the moment]
 
1) On some machines, there are periodic "pops" and "cracks" in both
directions in the     audio system.
 
2) Sometimes the audio system gets into a state where the input (from
the microphone) is replaced by a "loop" of previously captured audio,
about 1 second long.  When this happens, usually garbage of some sort is
played to the output.   We haven't been able to isolate the conditions
when this happens.
 
3) The output level control does not work properly on Win9x systems.
 
(1) and (2) is what we're working most diligently on right now.  There
may be some bug in the underlying audio code, _or_ it could be memory
corruption from somewhere unrelated.   (3) is probably unrelated, and
minor.
 
Has anyone on the list noticed something like this?
    
 
I generally see minor dropouts (causing very small but annoying pauses in
the audio) when I switch the focus from one application to another under
Windows.  I assumed this was simply the price of using a non-realtime,
non-kernel-level system.  Is this the same problem you are seeing?
  
I think we see that as well, but we get these pops, etc, even under nominal
loads.




In our debugging, we've found that we're getting these "pops" and stuff
from way down in the Win MME "waveXXX" APIs, though, so we're trying to
isolate it a bit from the rest of the code to see if that's the case.
    
 
Have you tried switching out the PA Windows MME module for the DirectX
module to see if that makes any difference?  While MME is "native" and
DirectX requires relatively current DirectX libraries, it does seem to me to
maintain better control over the audio stream it is playing.  The fact that
it requires the DX runtime is the only downside I can see.
  

And, my understanding is that the DX stuff has _much worse_ performance when
there aren't native DX drivers for your soundcard available -- in this case,
DX runs over WMME, and you get really high latencies.

For us, it's really a non-starter, because we are distributing this to users
who we cannot burden with needing to go and download extra DirectX stuff.
And we need to support 98SE as a baseline.

Maybe we'll revisit this sometime, like when we add Video to iaxclient..

-SteveK

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steve K. <st...@st...>]

Steven Sokol wrote:

>Now this is bizarre.  I _believe_ that your changes _have_ fixed the issue.
>However, I did my testing using a combination of clients, including Firefly.
>The issue, which never occurred firefly-to-firefly, DOES occur
>Firefly-to-IAX Phone, which is how I was testing.
>
>On a whim I changed my testing configuration to call IAX Phone-to-IAX Phone
>and using that setup, the calls never drop the audio.  Somehow the bug must
>still be in Adam's version of libiax2, but not surface when calling
>FF-to-FF.
>
>Does this indicate that there is still a bug in iaxClient since it does not
>interact properly with Firefly (which interacts properly with itself)?
>  
>
I don't know.   This bug might manifest itself in different ways, 
depending on how FF was implemented.  I don't know if Adam fixed the bug 
in his build or not.  If FF is not using a jitter buffer, the bug might 
not present itself in FF to FF calls (I'm not sure, though).  We saw the 
problem manifest itself in asterisk's jitter buffer.


>Steve K., thank you very much.  This has been a big stumbling block for me
>and you have given me what I needed to move forward.  1,000,000,000 points
>and a bucket of bits to you!
>  
>

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steve K. <st...@st...>]

It definitely should have made it to CVS, and I was curious about 
whether this would have affected people with this NAT problem.  (We're 
really only testing IAXclient <-> asterisk (w/ our app_conference) 
calls, not the more complicated IAXClient <-> asterisk <-> somewhere 
else calls with transfer and bridging, etc that other people are working 
on).

 Sourceforge anon CVS used to be a day (or two!) behind, but I believe 
that is not any longer, and I also have an _hourly_ tarball on the 
iaxclient.sf.net site which should be up to date.

You already put it in digium CVS, but I haven't checked.

For others here:   We are currently investigating some other problems 
inside of iaxclient;  particularly these two that may affect people:

[These issues seem to affect Win32 only at the moment]

1) On some machines, there are periodic "pops" and "cracks" in both 
directions in the     audio system. 

2) Sometimes the audio system gets into a state where the input (from 
the microphone) is replaced by a "loop" of previously captured audio, 
about 1 second long.  When this happens, usually garbage of some sort is 
played to the output.   We haven't been able to isolate the conditions 
when this happens.

3) The output level control does not work properly on Win9x systems.

(1) and (2) is what we're working most diligently on right now.  There 
may be some bug in the underlying audio code, _or_ it could be memory 
corruption from somewhere unrelated.   (3) is probably unrelated, and minor.

Has anyone on the list noticed something like this?

In our debugging, we've found that we're getting these "pops" and stuff 
from way down in the Win MME "waveXXX" APIs, though, so we're trying to 
isolate it a bit from the rest of the code to see if that's the case.

Anyone know a good strategy to do "valgrind" for Win32/gcc?  Last I 
checked [not too long ago] things were pretty clean with memory checkers 
under Linux and MacOSX.

-SteveK



Mark Spencer wrote:

>That should have mad its way into CVS already, right?
>
>Mark
>
>On Thu, 26 Feb 2004, Steve Kann wrote:
>
>  
>
>>Have you included the change that I made last week?  (where full frames
>>weren't being sent, only mini-frames?).
>>    
>>

RE: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steven S. <ss...@so...>]

Now this is bizarre.  I _believe_ that your changes _have_ fixed the issue.
However, I did my testing using a combination of clients, including Firefly.
The issue, which never occurred firefly-to-firefly, DOES occur
Firefly-to-IAX Phone, which is how I was testing.

On a whim I changed my testing configuration to call IAX Phone-to-IAX Phone
and using that setup, the calls never drop the audio.  Somehow the bug must
still be in Adam's version of libiax2, but not surface when calling
FF-to-FF.

Does this indicate that there is still a bug in iaxClient since it does not
interact properly with Firefly (which interacts properly with itself)?

Steve K., thank you very much.  This has been a big stumbling block for me
and you have given me what I needed to move forward.  1,000,000,000 points
and a bucket of bits to you!

Regards,

Steve S.

Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Mark S. <mar...@di...>]

That should have mad its way into CVS already, right?

Mark

On Thu, 26 Feb 2004, Steve Kann wrote:

>
> Have you included the change that I made last week?  (where full frames
> weren't being sent, only mini-frames?).
>
>
>
> Steven Sokol wrote:
>
> >IAXers,
> >
> >I have just spent the past hour testing out Adam Hart's Firefly client on my
> >system.  If you recall my diagram from several weeks ago, I have multiple
> >IAX2 clients behind a Linksys NAT box, all connecting to a single Asterisk
> >server on a public (non NAT) address.  Calls that are IAX2-IAX2 always die
> >off after 64-65 seconds.  This does not seem to happen with Firefly.  It
> >_does_ happen with DIAX and iaxComm, as well as IAX Phone.
> >
> >Adam has released his build of the libiax2 code.  I am going to try to swap
> >out the libiax2 that we are currently using for his version and see what
> >happens.  If the problem continues to occur with his code in place, I will
> >have to assume that the issue is within the iaxClient library code (either
> >in the call handshake portion, or in the audio handler) and that is what is
> >causing the issue.
> >
> >Can anybody think of any other considerations to take in this.  I would
> >really like to release the next version of IAX Phone, but I need to slay
> >this bug first.
> >
> >Help me Obi Wan Kenobi, you're my only hope...
> >
> >Steve S.
> >
> >Steven Sokol
> >Owner/Manager
> >Sokol & Associates, LLC
> >
> >Phone:  816.822.1807
> >IaxTel: 700.613.9004
> >Web:    http://www.sokol-associates.com
> >
> >
> >
> >
> >
> >-------------------------------------------------------
> >SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >Build and deploy apps & Web services for Linux with
> >a free DVD software kit from IBM. Click Now!
> >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >_______________________________________________
> >Iaxclient-devel mailing list
> >Iax...@li...
> >https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
> >
> >
> >
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Iaxclient-devel mailing list
> Iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>

Re: [Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steve K. <st...@st...>]

Have you included the change that I made last week?  (where full frames 
weren't being sent, only mini-frames?).



Steven Sokol wrote:

>IAXers,
>
>I have just spent the past hour testing out Adam Hart's Firefly client on my
>system.  If you recall my diagram from several weeks ago, I have multiple
>IAX2 clients behind a Linksys NAT box, all connecting to a single Asterisk
>server on a public (non NAT) address.  Calls that are IAX2-IAX2 always die
>off after 64-65 seconds.  This does not seem to happen with Firefly.  It
>_does_ happen with DIAX and iaxComm, as well as IAX Phone.
>
>Adam has released his build of the libiax2 code.  I am going to try to swap
>out the libiax2 that we are currently using for his version and see what
>happens.  If the problem continues to occur with his code in place, I will
>have to assume that the issue is within the iaxClient library code (either
>in the call handshake portion, or in the audio handler) and that is what is
>causing the issue.
>
>Can anybody think of any other considerations to take in this.  I would
>really like to release the next version of IAX Phone, but I need to slay
>this bug first.
>
>Help me Obi Wan Kenobi, you're my only hope...
>
>Steve S.
>
>Steven Sokol
>Owner/Manager
>Sokol & Associates, LLC
>
>Phone:  816.822.1807
>IaxTel: 700.613.9004
>Web:    http://www.sokol-associates.com
>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Iaxclient-devel mailing list
>Iax...@li...
>https://lists.sourceforge.net/lists/listinfo/iaxclient-devel
>
>  
>

[Iaxclient-devel] Any clues in the IAX2/NAT bug?

[Steven S. <ss...@so...>]

IAXers,

I have just spent the past hour testing out Adam Hart's Firefly client on my
system.  If you recall my diagram from several weeks ago, I have multiple
IAX2 clients behind a Linksys NAT box, all connecting to a single Asterisk
server on a public (non NAT) address.  Calls that are IAX2-IAX2 always die
off after 64-65 seconds.  This does not seem to happen with Firefly.  It
_does_ happen with DIAX and iaxComm, as well as IAX Phone.

Adam has released his build of the libiax2 code.  I am going to try to swap
out the libiax2 that we are currently using for his version and see what
happens.  If the problem continues to occur with his code in place, I will
have to assume that the issue is within the iaxClient library code (either
in the call handshake portion, or in the audio handler) and that is what is
causing the issue.

Can anybody think of any other considerations to take in this.  I would
really like to release the next version of IAX Phone, but I need to slay
this bug first.

Help me Obi Wan Kenobi, you're my only hope...

Steve S.

Steven Sokol
Owner/Manager
Sokol & Associates, LLC

Phone:  816.822.1807
IaxTel: 700.613.9004
Web:    http://www.sokol-associates.com

[Iaxclient-devel] Re: Bugfix in libiax2

[Mark S. <mar...@di...>]

Thanks, it's fixed.  It was correct in asterisk already, fortunately.

Mark

On Fri, 20 Feb 2004, Steve Kann wrote:

>
> Iaxclient-developers,
>
>     We just fixed a bug we found in libiax2, which caused it to never
> send full voice frames.  The basic problem is that the logic to check to
> see if we should send a full frame basically looks to see if the top
> half of the timestamp has changed, but it wasn't using the timestamp of
> the previous frame for the comparison, it was using the timestamp of the
> current frame.  Therefore, the top half will always be equal, and full
> frames will never be sent.
>
>     I'm not sure how this affects some of the problems that people were
> having with transferred calls, but it causes havoc to the jitterbuffer
> mechanism on asterisk servers.  This will likely screw up any calls to
> an asterisk server which has the jitterbuffer enabled (which is no
> longer the default, but seems pretty important for most internet calls).
>
>     The patch is below, and has been committed to sourceforge CVS.
>
>     Mark:  Please also apply this to digium libiax2 CVS if it looks
> correct to you.
>
> -SteveK
>
>
> Log Message:
> calc_timestamp modifies pvt->lastsent.  Therefore, the next test is always true, (since ts will ==
> lastsent), and we'll never send full audio frames.
>
> If we don't send full audio frames, we quickly screw up the jitterbuffer mechanism on the receiving
> asterisk server, because the timestamp wraps, and nothing ever corrects it.
>
> This fix follows the way this section of code works in chan_iax2.c
>
> -SK/JO
>
>
>
> Index: iax.c
> ===================================================================
> RCS file: /cvsroot/iaxclient/iaxclient/lib/libiax2/src/iax.c,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -d -r1.13 -r1.14
> --- iax.c	13 Feb 2004 22:20:01 -0000	1.13
> +++ iax.c	20 Feb 2004 22:26:51 -0000	1.14
> @@ -631,9 +631,12 @@
>  		return -1;
>  	}
>
> +	/* this must come before the next call to calc_timestamp() since
> +	 calc_timestamp() will change lastsent to the returned value */
> +	lastsent = pvt->lastsent;
> +
>  	/* Calculate actual timestamp */
>  	fts = calc_timestamp(pvt, ts);
> -	lastsent = pvt->lastsent;
>
>  	if (((fts & 0xFFFF0000L) == (lastsent & 0xFFFF0000L))
>  		/* High two bits are the same on timestamp, or sending on a trunk */ &&
>
>
>
>

[Iaxclient-devel] Bugfix in libiax2

[Steve K. <st...@st...>]

Iaxclient-developers,

    We just fixed a bug we found in libiax2, which caused it to never 
send full voice frames.  The basic problem is that the logic to check to 
see if we should send a full frame basically looks to see if the top 
half of the timestamp has changed, but it wasn't using the timestamp of 
the previous frame for the comparison, it was using the timestamp of the 
current frame.  Therefore, the top half will always be equal, and full 
frames will never be sent.

    I'm not sure how this affects some of the problems that people were 
having with transferred calls, but it causes havoc to the jitterbuffer 
mechanism on asterisk servers.  This will likely screw up any calls to 
an asterisk server which has the jitterbuffer enabled (which is no 
longer the default, but seems pretty important for most internet calls).

    The patch is below, and has been committed to sourceforge CVS.

    Mark:  Please also apply this to digium libiax2 CVS if it looks 
correct to you.

-SteveK


Log Message:
calc_timestamp modifies pvt->lastsent.  Therefore, the next test is always true, (since ts will ==
lastsent), and we'll never send full audio frames.

If we don't send full audio frames, we quickly screw up the jitterbuffer mechanism on the receiving
asterisk server, because the timestamp wraps, and nothing ever corrects it.

This fix follows the way this section of code works in chan_iax2.c

-SK/JO



Index: iax.c
===================================================================
RCS file: /cvsroot/iaxclient/iaxclient/lib/libiax2/src/iax.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- iax.c	13 Feb 2004 22:20:01 -0000	1.13
+++ iax.c	20 Feb 2004 22:26:51 -0000	1.14
@@ -631,9 +631,12 @@
 		return -1;
 	}
 	
+	/* this must come before the next call to calc_timestamp() since
+	 calc_timestamp() will change lastsent to the returned value */
+	lastsent = pvt->lastsent;
+
 	/* Calculate actual timestamp */
 	fts = calc_timestamp(pvt, ts);
-	lastsent = pvt->lastsent;
 
 	if (((fts & 0xFFFF0000L) == (lastsent & 0xFFFF0000L))
 		/* High two bits are the same on timestamp, or sending on a trunk */ &&

[Iaxclient-devel] Another IAX soft phone based on Dan's DLL

[<gr...@ho...>]

"Call2CN" another IAX soft phone based on Dan's DLL. Used to make =
international long distance calls to China with lowest rate. The =
homepage is http://call2cn.3322.org

Re: [Iaxclient-devel] IAX2 calls dropping afet 65 secs -- solved?

[Steve K. <st...@st...>]

Michael Van Donselaar wrote:

>Steve Sokol and I have been trying to track down this problem for quite some
>time.
>
>I think that the problem had nothing to do with scheduling, but with native
>transfers.
>
>(I think that iax.conf needs a canreinvite parameter, like sip.conf)
>
>I changed the debug code to print to a log file (since wxWindows appears to eat
>stderr) and found that the problems seemed to be occurring when asterisk sent a
>TXREQ and the softphone sent a TXCNT.  And another TXCNT.  And another TXCNT.
>And .....  the asterisk sent several TXREJs and then audio stopped flowing.
>
>I tried to follow the chan-iax2 code in the asterisk code, but then looked at
>the iaxlib code on the digium ftp site.
>
>Then I looked at the CVS *libiax2* code.  Aha, we're out of date.  I noticed
>that we weren't applying the apparent_address when we were sending our TXCNT, so
>I just copied the iax.c from digium's libiax2 CVS into the iaxclient's
>libiax2/src and recompiled.
>
>IT WORKS (mostly)
>
>iaxComm -> asterisk -> iaxComm works fine if there's no NAT anywhere in the
>picture.
>
>Steve Sokol tells me that 
>
>iax Phone ->|
>            |linksys router -> asterisk
>iax Phone ->|
>
>doesn't work.
>
>I've found that
>
>iaxComm -> asterisk -> NAT VPN -> iaxComm
>
>doesn't work.
>
>Steve Kann:  I'd like to update the iaxclient CVS to have iax.c from digium, but
>with the addition of Steve Sokol's blind_transfer function, OK?
>  
>

There looks like there's a few changes; I really need to synch us up 
properly, because we have a couple of other fixes in there other than 
the blind transfer stuff.

In iax.c itself:

1) A couple of fixes for non-GNU C (but not complete).
-#ifdef __GNUC__
        f.src = __FUNCTION__;
-#else
-       f.src = __FILE__;
-#endif

2) A fix for plaintext passwords.
        } else {
-               iax_ie_append_str(&ied, IAX_IE_MD5_RESULT, password);
+               iax_ie_append_str(&ied, IAX_IE_PASSWORD, password);
        }

3) Steve U's fixes for some lost frames:
-                       /* Queue for immediate delivery */
-                       iax_sched_event(e, NULL, 0);
-                       return NULL;
-                       //return e;
+                       return e;
 [and more]


4) A memory allocation fix.
-       e = (struct iax_event *)malloc(sizeof(struct iax_event) + 
datalen + 1);
+       e = (struct iax_event *)malloc(sizeof(struct iax_event) + datalen);


Also, there's similar changes in the other side.

The two changes you're referring to:
1.17         (markster 04-Dec-03):      return send_command(session, 
AST_FRAME_IAX, IAX_COMMAND_TXREADY, 0, ied.buf, ied.pos, -1);

and
1.17         (markster 04-Dec-03):                              
session->transfer = *e->ies.apparent_addr;

were obviously committed by mark in Early December..

Here's what he wrote to the log:
----------------------------
revision 1.17
date: 2003/12/04 22:20:38;  author: markster;  state: Exp;  lines: +2 -1
libiax2 fix

=============

anyway, Michael, you can commit those two changes to our version if you 
want, or I will do this sometime early next week.  I do need to go 
through and synchronize the versions and send a patch over to Mark with 
the changes, and notes on who is contributing the changes.

-SteveK

[Iaxclient-devel] IAX2 calls dropping afet 65 secs -- solved?

[Michael V. D. <mv...@va...>]

Steve Sokol and I have been trying to track down this problem for quite =
some
time.

I think that the problem had nothing to do with scheduling, but with =
native
transfers.

(I think that iax.conf needs a canreinvite parameter, like sip.conf)

I changed the debug code to print to a log file (since wxWindows appears =
to eat
stderr) and found that the problems seemed to be occurring when asterisk =
sent a
TXREQ and the softphone sent a TXCNT.  And another TXCNT.  And another =
TXCNT.
And .....  the asterisk sent several TXREJs and then audio stopped =
flowing.

I tried to follow the chan-iax2 code in the asterisk code, but then =
looked at
the iaxlib code on the digium ftp site.

Then I looked at the CVS *libiax2* code.  Aha, we're out of date.  I =
noticed
that we weren't applying the apparent_address when we were sending our =
TXCNT, so
I just copied the iax.c from digium's libiax2 CVS into the iaxclient's
libiax2/src and recompiled.

IT WORKS (mostly)

iaxComm -> asterisk -> iaxComm works fine if there's no NAT anywhere in =
the
picture.

Steve Sokol tells me that=20

iax Phone ->|
            |linksys router -> asterisk
iax Phone ->|

doesn't work.

I've found that

iaxComm -> asterisk -> NAT VPN -> iaxComm

doesn't work.

Steve Kann:  I'd like to update the iaxclient CVS to have iax.c from =
digium, but
with the addition of Steve Sokol's blind_transfer function, OK?

Michael (aka Steve V)