Commit Graph

8 Commits

Author SHA1 Message Date
David Vossel
c26c190711 Asterisk media architecture conversion - no more format bitfields
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal.  For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal

The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs.  Functionally
no change in behavior should be present in this patch.  Thanks to twilson
and russell for all the time they spent reviewing these changes.

Review: https://reviewboard.asterisk.org/r/1083/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-02-03 16:22:10 +00:00
Tilghman Lesher
317429294c Merged revisions 279472 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r279472 | tilghman | 2010-07-25 22:27:06 -0500 (Sun, 25 Jul 2010) | 2 lines
  
  Formats need to load before apps, because some apps call ast_format_str_reduce() at load time.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-26 03:28:02 +00:00
Tilghman Lesher
b4e18d5660 Add load priority order, such that preload becomes unnecessary in most cases
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-20 19:35:02 +00:00
Russell Bryant
8ab22f5dd0 Set a module load priority for format modules.
A recent change to app_voicemail made it such that the module now assumes that
all format modules are available while processing voicemail configuration.
However, when autoloading modules, it was possible that app_voicemail was
loaded before the format modules.  Since format modules don't depend on
anything, set a module load priority on them to ensure that they get loaded
first when autoloading.

This fix applies to trunk, 1.6.1, and 1.6.2.  The fix for 1.4 and 1.6.0 will
require a different approach since the module load priority functionality is
not present in the module API.

(issue #16412)
Reported by: jiddings


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@233692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-12-08 18:00:16 +00:00
Tilghman Lesher
d8e0c58437 Expand codec bitfield from 32 bits to 64 bits.
Reviewboard: https://reviewboard.asterisk.org/r/416/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-11-04 14:05:12 +00:00
Michiel van Baak
f1e9371da8 - revert change to ast_queue_hangup and create ast_queue_hangup_with_cause
- 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
2008-05-22 16:29:54 +00:00
Russell Bryant
a82ab5369e minor formatting changes
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@97804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-01-10 17:30:24 +00:00
Kevin P. Fleming
a20b146df5 add a file-format driver for 16KHz signed linear... which may or may not work
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@96862 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-01-07 16:17:31 +00:00