Re: [asterisk-dev] ast_frame allocation/free question
On Tuesday 27 November 2007 15:11:14 Kevin P. Fleming wrote: > This makes no sense; once chan_sip has fed you a frame of audio data, > why should it care who frees it, and more importantly, how could it > possibly know that the frame is no longer needed? This is getting me very confused. Isn't it exactly the same situation that the app faces? Once the app has fed the channel a frame of audio data, how could it possibly know that the frame is no longer needed? ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_frame allocation/free question
From: "Kevin P. Fleming" <[EMAIL PROTECTED]> > Sergio Garcia Murillo wrote: > > > I agree, but I think that it's a usually a good practice that the one that > > allocates > > the memory is the reponsible of freeing it. What I don't really see is why > > the > > apps need to call the ast_frfree on frames they have just readen. > > This makes no sense; once chan_sip has fed you a frame of audio data, > why should it care who frees it, and more importantly, how could it > possibly know that the frame is no longer needed? > Just changing your phrase: This makes no sense; once my applicaton has fed you a frame of audio data, why should it care who frees it, and more importantly, how could it possibly know that the frame is no longer needed? Best regards Sergio ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_frame allocation/free question
Sergio Garcia Murillo wrote: > I agree, but I think that it's a usually a good practice that the one that > allocates > the memory is the reponsible of freeing it. What I don't really see is why > the > apps need to call the ast_frfree on frames they have just readen. This makes no sense; once chan_sip has fed you a frame of audio data, why should it care who frees it, and more importantly, how could it possibly know that the frame is no longer needed? -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Zaptel 1.2.22 and 1.4.7 released
The Asterisk.org development team has announced the release of Zaptel versions 1.2.22 and 1.4.7. These releases contain (among other things) many bug fixes to the TC400B driver, a bug fix on the wctdm24xxp driver for users with a VPM150M, as well as numerous improvements and fixes to the Xorcom driver suite. The much better performing version of fxotune from 1.4 has now been put into 1.2, so you may wish to rerun this tool with the new version. As always, please see the respective Changelogs for additional information. Both releases are available as a tarball as well as a patch against the previous release. They are available for download from downloads.digium.com. Thank you for your support! ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_frame allocation/free question
From: "Kevin P. Fleming" <[EMAIL PROTECTED]> > Sergio Garcia Murillo wrote: > > > So if you're writting a custom application you have to take care for > > deleting the > > frames you write and the frames you read, but if you write a custom channel > > you > > don't have to worry? > > Shouldn't be better to have a general policy about it, for example the one > > that creates > > the frame has to take care of deleting it, or the one that consumes the > > frame is the one > > that deletes it. Just as an idea, as I said before I've just made > > everything static and > > fixed my problem. > > So what is your definition of 'consume'? The application you are writing > is the one that is 'consuming' the frames. If ast_write() was the > consumer, then you'd never be able to write the frame to more than one > location without duplicating it, which would be needless overhead. > I agree, but I think that it's a usually a good practice that the one that allocates the memory is the reponsible of freeing it. What I don't really see is why the apps need to call the ast_frfree on frames they have just readen. Also as Russell pointed I perhaps should be using the ast_frame_header_new() if i really need to dinamically allocate frames. BR Sergio ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
Tzafrir Cohen wrote: > On Tue, Nov 27, 2007 at 11:06:19AM -0600, Russell Bryant wrote: >> Eliel Sardanons wrote: >>> We could start a janitor for creating a 'foo reload' and we could make >>> de 'module reload *.so' do a module unload; module load >> I would rather not change the behavior of "module reload". I think that >> would >> be much worse than just removing it, as it changes behavior that has existed >> for >> years. Running "module unload / module load" isn't that bad. > > What's so bad about having some syntactic sugar? And actually having > some stable CLI between two releases? > I don't think I understand what you're trying to imply here. Which part are you agreeing or disagreeing with? -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
Tilghman Lesher wrote: > On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote: >> - Remove the 'reload()' handler function on every module. > > I wouldn't do this last one. That is the handler that is called when we do > a generic 'reload', for every single module. Ah, good catch. Agreed ... -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] delaying few seconds for FAS problem
Hi, Your ATAs are buggy or do not handle / pass progress in band information properly. Unfortunately, there isn't much you can do. Flash the firmware pehaps? 2007/11/27, robert santos <[EMAIL PROTECTED]>: > gud day, > > hope this is not OT. currently encountering problem with ATA FXO FAS problem > especially on CDR. > > the scenario is dis: > ATA of grandstream and sipura, send 183 and 200 simultaneously even if the > FXO port is not yet ringing. > since 200 was receive already then CDR starts the timer. not good for a > prepaid system > > research: > all documents that i have read points me to a blank wall. > > possible workaround: > upon receiving of 200 delay for a while so that CDR does not start > immediately. prepaid customer is not > that much. > > help: > im asking the developers if this is possible? how can i do this.. > > all help is welcome, regards > arvin > > > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_frame allocation/free question
Sergio Garcia Murillo wrote: > So if you're writting a custom application you have to take care for > deleting the > frames you write and the frames you read, but if you write a custom channel > you > don't have to worry? > Shouldn't be better to have a general policy about it, for example the one > that creates > the frame has to take care of deleting it, or the one that consumes the > frame is the one > that deletes it. Just as an idea, as I said before I've just made > everything static and > fixed my problem. So what is your definition of 'consume'? The application you are writing is the one that is 'consuming' the frames. If ast_write() was the consumer, then you'd never be able to write the frame to more than one location without duplicating it, which would be needless overhead. -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_frame allocation/free question
- Original Message -
From: "Russell Bryant" <[EMAIL PROTECTED]>
To: "Asterisk Developers Mailing List"
Sent: Tuesday, November 27, 2007 5:17 PM
Subject: Re: [asterisk-dev] ast_frame allocation/free question
> Sergio Garcia Murillo wrote:
> > I've been trying to fix some memory leaks in my applications related
> > to frame allocation problems.
> > If I malloc a frame in an application and set the mallocd to
AST_MALLOCD_HDR
> > it seems that ast_frfree is not called nowhere after writing it with
ast_write.
> >
> > I have checked and ast_write don't call ast_frfree for the input frame.
In
> > case of a video frame just calls chan->tech->write(chan, fr) but in
rtp.c it's
> > not freed also.
>
> The code is correct. ast_write() should not free the frame. It is the
caller
> of ast_write() who must free the frame. In the most general case, this is
done
> in the bridging functions such ast ast_generic_bridge() in channel.c. It
reads
> a frame using ast_read(), writes it to the other channel with ast_write(),
and
> then frees it.
> > I've solved the problem in some cases making the frame static and in
oder cases
> > setting mallocd to 0 and freeing it withing the application after using
it.
>
> You certainly should use a single frame structure over and over whenever
> possible, as it is more efficient. If you must allocate a frame,
ast_frdup()
> may do what you need. If that doesn't do it, then you should probably
expose
> ast_frame_header_new() from frame.c, as it takes advantage of cached frame
headers.
>
But it's not a bit incoherent? I mean, in many applications that comes with
asterisk I
can see the following:
/* Do our thing here */
while (ast_waitfor (chan, -1) > -1 && !h.hangup)
{
f = ast_read (chan);
if (!f)
break;
if (f->frametype == AST_FRAME_VOICE) {
sms_process (&h, f->samples, f->data);
}
ast_frfree (f);
}
So if you're writting a custom application you have to take care for
deleting the
frames you write and the frames you read, but if you write a custom channel
you
don't have to worry?
Shouldn't be better to have a general policy about it, for example the one
that creates
the frame has to take care of deleting it, or the one that consumes the
frame is the one
that deletes it. Just as an idea, as I said before I've just made
everything static and
fixed my problem.
BR
Sergio
___
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
Tilghman Lesher wrote: > On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote: > >> On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote: >> >>> Eliel Sardanons wrote: >>> We could start a janitor for creating a 'foo reload' and we could make de 'module reload *.so' do a module unload; module load >>> I would rather not change the behavior of "module reload". I think that >>> would be much worse than just removing it, as it changes behavior that >>> has existed for years. Running "module unload / module load" isn't that >>> bad. >>> >> So: >> - Start a janitor to implement 'foo reload' for every module that does >> something in the reload() handler function. >> - Deprecate CLI command 'module reload ' >> - Remove the 'reload()' handler function on every module. >> > > I wouldn't do this last one. That is the handler that is called when we do > a generic 'reload', for every single module. > > I agree with Tilghman. -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
On Tue, Nov 27, 2007 at 11:06:19AM -0600, Russell Bryant wrote: > Eliel Sardanons wrote: > > We could start a janitor for creating a 'foo reload' and we could make > > de 'module reload *.so' do a module unload; module load > > I would rather not change the behavior of "module reload". I think that would > be much worse than just removing it, as it changes behavior that has existed > for > years. Running "module unload / module load" isn't that bad. What's so bad about having some syntactic sugar? And actually having some stable CLI between two releases? -- Tzafrir Cohen icq#16849755 jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
On Tuesday 27 November 2007 11:26:34 Eliel Sardanons wrote: > On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote: > > Eliel Sardanons wrote: > > > We could start a janitor for creating a 'foo reload' and we could make > > > de 'module reload *.so' do a module unload; module load > > > > I would rather not change the behavior of "module reload". I think that > > would be much worse than just removing it, as it changes behavior that > > has existed for years. Running "module unload / module load" isn't that > > bad. > > So: > - Start a janitor to implement 'foo reload' for every module that does > something in the reload() handler function. > - Deprecate CLI command 'module reload ' > - Remove the 'reload()' handler function on every module. I wouldn't do this last one. That is the handler that is called when we do a generic 'reload', for every single module. -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-commits] file: trunk r89637 - /trunk/main/utils.c
- Original Message - From: Simon Perreault [mailto:[EMAIL PROTECTED] To: asterisk-dev@lists.digium.com Sent: Tue, 27 Nov 2007 13:06:36 -0400 Subject: Re: [asterisk-dev] [asterisk-commits] file: trunk r89637 - /trunk/main/utils.c > On Tuesday 27 November 2007 12:01:19 SVN commits to the Asterisk project > wrote: > > + long int rm = RAND_MAX; > > res = res < 0 ? ~res : res; > > - return res; > > + rm++; > > + return res % rm; > > Hum... Won't rm be zero on 32-bit platforms? Modulo zero isn't defined in > C... I tested both platforms before putting the change in and it worked fine on both, but it could be undefined. More exploring is required I suppose. Joshua Colp Software Developer Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
So: - Start a janitor to implement 'foo reload' for every module that does something in the reload() handler function. - Deprecate CLI command 'module reload ' - Remove the 'reload()' handler function on every module. Eliel On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote: > Eliel Sardanons wrote: > > We could start a janitor for creating a 'foo reload' and we could make > > de 'module reload *.so' do a module unload; module load > > I would rather not change the behavior of "module reload". I think that would > be much worse than just removing it, as it changes behavior that has existed > for > years. Running "module unload / module load" isn't that bad. > > -- > Russell Bryant > Senior Software Engineer > Open Source Team Lead > Digium, Inc. > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Eliel Sardañons ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-commits] file: trunk r89637 - /trunk/main/utils.c
On Tuesday 27 November 2007 12:01:19 SVN commits to the Asterisk project wrote: > + long int rm = RAND_MAX; > res = res < 0 ? ~res : res; > - return res; > + rm++; > + return res % rm; Hum... Won't rm be zero on 32-bit platforms? Modulo zero isn't defined in C... ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
Eliel Sardanons wrote: > We could start a janitor for creating a 'foo reload' and we could make > de 'module reload *.so' do a module unload; module load I would rather not change the behavior of "module reload". I think that would be much worse than just removing it, as it changes behavior that has existed for years. Running "module unload / module load" isn't that bad. -- Russell Bryant Senior Software Engineer Open Source Team Lead Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deprecate every '* reload' CLI command?
I agree with the idea of starting a new Janitor to update the modules to use ' reload' and change the behaviour of module reload to unload and load the module. This way, ' reload' should reparse the configuration file and 'module reload' should unload and load the module. Also, I think this should be documented in some doc for the sake of consistency to users and developers in future releases. Best regards, Tomás. On Nov 27, 2007 1:39 PM, Eliel Sardanons <[EMAIL PROTECTED]> wrote: > We could start a janitor for creating a 'foo reload' and we could make > de 'module reload *.so' do a module unload; module load > > > On 11/27/07, Russell Bryant <[EMAIL PROTECTED]> wrote: > > Kevin P. Fleming wrote: > > > I would be surprised if any module's 'reload' command actually did > much > > > of anything different than 'module reload' for the same module does, > but > > > as BJ points out there certainly is no reason that they have to > provide > > > the same functionality. > > > > They better not do anything different. :) If they do, I would > definitely > > consider it a bug. That would be frustratingly inconsistent. > > > > > I think adding a 'voicemail reload' command is a fine idea. > > > > Well, I guess I agree that it is fine because it is a bit more user > friendly > > than "module reload app_voicemail.so". However, I don't think we can > leave the > > conversation at that. > > > > The Asterisk CLI syntax got significantly switched around for Asterisk > 1.4 for > > the sake of consistency. This issue points to another area where the > Asterisk > > CLI is not consistent. We need to pick one way or the other and stick > with it. > > If people really like the idea of having individual reload CLI commands > like > > "voicemail reload", then I say that we should: > > > > 1) Start a janitor project to go through the code base and implement > "foo > > reload" CLI commands for _every_ module that implements a reload module > callback > > function. > > > > 2) Mark the "module reload res_foo.so" syntax as deprecated and > eventually > > completely remove it. This syntax was always confusing to me when I > started > > with Asterisk, because I thought it was equivalent to "module unload / > module load". > > > > -- > > Russell Bryant > > Senior Software Engineer > > Open Source Team Lead > > Digium, Inc. > > > > ___ > > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > > > asterisk-dev mailing list > > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > > -- > Eliel Sardañons > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
