own repository, and must be installed like any other library for Asterisk to
use. The two modules that require it are codec_resample and app_jack.
To install libresample:
$ svn co http://svn.digium.com/svn/libresample/trunk libresample
$ cd libresample
$ ./configure
$ make
$ sudo make install
This code is currently in our own repository because the build system did not
include the appropriate targets for building a dynamic library or for installing
the library.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r125132 | kpfleming | 2008-06-25 17:21:30 -0500 (Wed, 25 Jun 2008) | 10 lines
allow tonezone to live in a different place than DAHDI/Zaptel, since dahdi-tools and dahdi-linux are now separate packages and can be installed in different places
don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@125138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- make data member of the ast_frame struct a named union instead of a void
Recently the ast_queue_hangup function got a new parameter, the hangupcause
Feedback came in that this is no good and that instead a new function should be created.
This I did.
The hangupcause was stored in the seqno member of the ast_frame struct. This is not very
elegant, and since there's already a data member that one should be used.
Problem is, this member was a void *.
Now it's a named union so it can hold a pointer, an uint32 and there's a padding in case someone
wants to store another type in there in the future.
This commit is so massive, because all ast_frame.data uses have to be
altered to ast_frame.data.data
Thanks russellb and kpfleming for the feedback.
(closes issue #12674)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@117802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111856 | qwell | 2008-03-28 16:45:35 -0500 (Fri, 28 Mar 2008) | 12 lines
Allow gsm to compile correctly on x86 with gcc4 optimizations.
(closes issue #11243)
Reported by: whiskerp
Patches:
11243-maybe-asm.diff uploaded by qwell (license 4)
Tested by: Seggy (IRC)
Note: While I did write this patch, I would not have found this if fossil
had not reported and fixed issue #12253. A huge thanks to him for helping
to (indirectly) find the problem here.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@111857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r110880 | kpfleming | 2008-03-26 09:42:35 -0700 (Wed, 26 Mar 2008) | 10 lines
Merged revisions 110869 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110869 | kpfleming | 2008-03-26 08:53:46 -0700 (Wed, 26 Mar 2008) | 2 lines
due to licensing restrictions, we cannot distribute the source code for iLBC encoding and decoding... so remove it, and add instructions on how the user can obtain it themselves
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@110881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.
main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
frame must be divided by 2 before being sent out over the network. Even
though G722 is 16 kHz, an error in some previous spec has made it so that
we have to list the number of samples such as if it was 8 kHz.
main/file.c:
- When scheduling the next time to expect a frame, take into account that the
format of the file we're reading from may not be 8 kHz.
codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
parameter to be in the silly (real samples / 2) format. Make it so.
- When converting from slinear to G722, properly set the number of samples in
the frame to be the number of bytes of output * 2.
formats/format_pcm.c:
- This format module handles G722, among a number of other formats. However,
the read() and seek() functions did not account for the fact that G722 has
2 samples per byte.
(closes issue #12130, reported by rickross, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a value from a double, to a float, back to a double. Sure enough, when I changed
my interim variable back to a double, it still blows up. Switching all of these
to a float fixes the problem. This seems like a compiler bug where a double passed
as an argument isn't getting properly aligned, so I'll have to see if I can replicate
it with a small test program.
(related to issue #11725)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with platforms that explode on unaligned access. I'm not exactly sure why
this fixes it, but it fixed it on the machine I was testing on. If it makes
sense to you, feel free to enlighten me. :)
(closes issue #11725, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
framein callbacks different. However, they are now the same again, so remove
the duplicate code and use the same functions for the lin/lin16 versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sample length with g722. It is _2_ samples per byte, not 1. This was all
over the place, and I believed it, and it is what caused me to take so long
to figure out what was broken.
- Update copyright information on codec_g722.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- The most common fix being made here is to fix all of the places where the
number of output samples and output bytes gets updated in the translator
state structure.
- Fix a number of other places where the number of samples provided as an
initialization value to a struct was incorrect.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_resample, and mark codec_resample as dependent upon res_resample. This
prevents the linker from optimizing away libresample, and also makes it so the
libresample code isn't linked in to multiple places. (I have another module
in a branch that needs it, too.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(and probably other systems as well).
Both need libresample.a to be specified in the linking phase,
and cygwin needs <float.h> as other BSD.
The checks for OS-specific headers should really be moved to some
common header though.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit imports libresample for use in Asterisk. It also adds a new codec
module, codec_resample. This module uses libresample to re-sample signed linear
audio between 8 kHz and 16 kHz.
It also provides an alternative for converting between 16 kHz G.722 and 8 kHz
signed linear when using G.722, which will likely be useful as some people have
complained about volume issues when the current codec_g722 converts to 8 kHz
signed linear. But, to test this, you will have to disable the g722-to-slin and
g722-to-slin16 translators in codec_g722.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@95501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93180 | kpfleming | 2007-12-16 22:44:51 -0800 (Sun, 16 Dec 2007) | 23 lines
In http://lists.digium.com/pipermail/asterisk-dev/2007-December/031145.html,
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generate loadable and embedded module lists.
Individual Makefiles now are a lot simpler, possibly as simple as this:
-include $(ASTTOPDIR)/menuselect.makeopts $(ASTTOPDIR)/menuselect.makedeps
MODULE_PREFIX=cdr_
all: _all
include $(ASTTOPDIR)/Makefile.moddir_rules
and also more flexible because in a single directory we can combine
various types of modules (app_, cdr_, func_, ... ) by simply
listing them in the MODULE_PREFIX variable.
The individual Makefiles can also create list of modules to be
excluded by listing them in the variablel MODULE_EXCLUDE (see an
example in channels/Makefile).
With this change it becomes trivial to integrate a directory with
locally created/modified sources into the main build.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@92082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
build times - tested, there is no measureable difference before and
after this commit.
In this change:
use asterisk/compat.h to include a small set of system headers:
inttypes.h, unistd.h, stddef.h, stddint.h, sys/types.h, stdarg.h,
stdlib.h, alloca.h, stdio.h
Where available, the inclusion is conditional on HAVE_FOO_H as determined
by autoconf.
Normally, source files should not include any of the above system headers,
and instead use either "asterisk.h" or "asterisk/compat.h" which does it
better.
For the time being I have left alone second-level directories
(main/db1-ast, etc.).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- the *_CURRENT macros no longer need the list head pointer argument
- add AST_LIST_MOVE_CURRENT to encapsulate the remove/add operation when moving entries between lists
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Remove the AST_FORMAT_MAX_* types, as these are consuming 3 out of our available 32 bits.
- Add a native slin16 type, so that 16kHz codecs can translate without losing resolution.
(This doesn't affect anything immediately, until another codec has wb support.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also fixes a few cli messages and some minor formatting.
(closes issue #11001)
Reported by: seanbright
Patches:
newcli.1.patch uploaded by seanbright (license 71)
newcli.2.patch uploaded by seanbright (license 71)
newcli.4.patch uploaded by seanbright (license 71)
newcli.5.patch uploaded by seanbright (license 71)
newcli.6.patch uploaded by seanbright (license 71)
newcli.7.patch uploaded by seanbright (license 71)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@86534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
external libraries and URLs to these. Please help me add these
references.
We might want to create a similar macro "\linuxpackage" to list
the needed Linux packages in popular distributions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@56647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r52997 | russell | 2007-01-30 17:23:24 -0600 (Tue, 30 Jan 2007) | 5 lines
When we are checking for a system installed version of libgsm, we need to check
for gsm.h as well. Furthermore, when checking for this header, it may be
located in a gsm/ sub directory, so check for that, as well.
(issue #8773)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@52998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49457 | kpfleming | 2007-01-04 12:05:47 -0600 (Thu, 04 Jan 2007) | 2 lines
make building of codec_gsm against the system GSM library actually work
........
r49460 | kpfleming | 2007-01-04 12:16:40 -0600 (Thu, 04 Jan 2007) | 2 lines
don't define this type either if LOW_MEMORY is enabled
........
r49461 | kpfleming | 2007-01-04 12:17:01 -0600 (Thu, 04 Jan 2007) | 2 lines
don't do frame header caching in the core if LOW_MEMORY is defined
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49102 | kpfleming | 2007-01-01 17:34:35 -0600 (Mon, 01 Jan 2007) | 2 lines
check specifically for VLDTMF and transcoding support in the system's Zaptel installation, and make only the modules that need those features dependent on them (this will allow building the other Zaptel-using parts of Asterisk against older versions of Zaptel or those on other platforms that haven't caught up yet to the Linux version)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- with AST_DEVMODE, building codecs/lpc10 fails because of lots
of warnings, and the configure step in editline fails as well.
Fix this by removing the -Werror in these steps.
- on FreeBSD (but probably on other platforms as well), the final
link of asterisk fails because AST_LIBS was not exported to the
subdirs Makefiles. Add a proper fix in the top-level Makefile
(a possible alternative way is to add "export AST_LIBS" near
the beginning of the file).
With this fix, i believe that some of the platform-specific
conditionals in main/Makefile are redundant (because they should
be already dealt with in the top level Makefile) but i don't
have a platform to check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@44081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@40722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
astmm support and astmm doesn't get really upset and complain that it is being
asked to free memory that was never allocated
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I don't particular like the approach, which basically tries to exclude the file based on
NOT being in a list of arches. This, IMHO, is backwards, it should be a list of AMD arches
instead. "Better to light a candle, than to curse the darkness", is apropo here. But since I don't
have an exhaustive list of what those arches could be, I leave as-is for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@38187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
split support for G726-32 into RFC3551 and AAL2 packing orders, since both are in use
change "G726-32" to be RFC3551 packing order, in spite of devices that use AAL2 order with this MIME type
add ability to directly transcode between packing orders
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@37494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
support the new location for zaptel.h and tonezone.h
use the dependency information output by menuselect to build Makefile rules for each module for header files and libraries
combine the common rules into a top-level Makefile.rules file
remove all (now) unnecessary stuff from subdir Makefiles
change translator API so that the newpvt() callback returns an int instead of a pointer (it no longer allocates memory)
alphabetize --with-<foo> options in configure script
enhance Net-SNMP support in configure script to provide a --with-netsnmp option
fix support for --with-pq so that if pg-config is not found when --with-pq is specified, an error will be generated
add 'optional package' usage to modules now that menuselect can output it
allow res_snmp to build by default, since the new loader changes coming soon will solve the function naming problem (and users can disable it via menuselect anyway)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
subdirectory instead of a for loop
- remove the FORCE target from the main Makefile and add the couple places
I used it to the .PHONY target. .PHONY does the same thing and is a built-in
more efficient way of doing it.
- add a bunch more targets to .PHONY ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- add a copyright header to the build_tools Makefile
- remove 'depend' from the 'all' target in agi/ and utils/ since it is handled
by the main Makefile already
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since they are targets that do not have resulting files and are never listed
as prerequisites to real targets. Using .PHONY in this manner improves make
performance by never having to check for resulting files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@35415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
file is generated. This allows a fresh checkout of asterisk to be built
and installed with the standard "./configure && make && make install".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@32798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As partly documented in loader.c and include/asterisk/module.h,
modules are now expected to return all of their methods and flags
into a structure 'mod_data', and are normally loaded with RTLD_NOW
| RTLD_LOCAL, so symbols are resolved immediately and conflicts
should be less likely. Only in a small number of cases (res_*,
typically) modules are loaded RTLD_GLOBAL, so they can export
symbols.
The core of the change is only the two files loader.c and
include/asterisk/module.h, all the rest is simply adaptation of the
existing modules to the new API, a rather mechanical (but believe
me, time and finger-consuming!) process whose detail you can figure
out by svn diff'ing any single module.
Expect some minor compilation issue after this change, please
report it on mantis http://bugs.digium.com/view.php?id=6968
so we collect all the feedback in one place.
I am just sorry that this change missed SVN version number 20000!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@20003 65c4cc65-6c06-0410-ace0-fbb531ad65f3