Due to changes in audiohooks to support different sample rates the
underlying storage of samples is in the format of the audiohook
itself and not of the format being requested. This means that if a
channel is using G722 the samples stored will be at 16kHz. If
something subsequently reads from the audiohook at a format which
is not the same sample rate as the audiohook the number of samples
needs to be adjusted.

Given the following example:
1. Channel writing into audiohook at 16kHz (as it is using G722).
2. Chanspy reading from audiohook at 8kHz.

The original code would read 160 samples from the audiohook for
each 20ms of audio. This is incorrect. Since the audio in the
audiohook is at 16kHz the actual number needing to be read is 320.
Failure to read this much would cause the audiohook to reset
itself constantly as the buffer became full.

This change adjusts the requested number of samples by determining
the duration of audio requested and then calculating how many
samples that would be in the audiohook format.

ASTERISK-25247 #close

Change-Id: Ia91ce516121882387a315fd8ee116b118b90653d

Currently, everytime a sample rate change occurs (on read or write) the
associated factory buffers are reset. If the requested sample rate on a
read differed from that of a write then the buffers are continually reset
on every read and write. This has the side effect of emptying the buffer,
thus there being no data to read and then write to a file in the case of
call recording.

This patch fixes it so that an audiohook_list's rate always maintains the
maximum sample rate among hooks and formats. Audiohook sample rates are
only overwritten by this value when slin native compatibility is turned on.
Also, the audiohook sample rate can only overwrite the list's sample rate
when its rate is greater than that of the list or if compatibility is
turned off. This keeps the rate from constantly switching/resetting.

ASTERISK-24944 #close
Reported by: Ronald Raikes

Change-Id: Idab4dfef068a7922c09cc631dda27bc920a6c76f

When an audiohook is created (which is used by the various Spy applications
and Snoop channel in Asterisk 13+), it initially is given a sample rate of
8kHz. It is expected, however, that this rate may change based on the media
that passes through the audiohook. However, the read/write operations on the
audiohook behave very differently.

When a frame is written to the audiohook, the format of the frame is checked
against the internal sample rate. If the rate of the format does not match
the internal sample rate, the internal sample rate is updated and a new SLIN
format is chosen based on that sample rate. This works just fine.

When a frame is read, however, we do something quite different. If the format
rate matches the internal sample rate, all is fine. However, if the rates
don't match, the audiohook attempts to "fix up" the number of samples that
were requested. This can result in some seriously large number of samples
being requested from the read/write factories.

Consider the worst case - 192kHz SLIN. If we attempt to read 20ms worth of
audio produced at that rate, we'd request 3840 samples (192000 / (1000 / 20)).
However, if the audiohook is still expecting an internal sample rate of 8000,
we'll attempt to "fix up" the requested samples to:

  samples_converted = samples * (ast_format_get_sample_rate(format) /
                                 (float) audiohook->hook_internal_samp_rate);

  which is:

  92160 = 3840 * (192000 / 8000)

This results in us attempting to read 92160 samples from our factories, as
opposed to the 3840 that we actually wanted. On a 64-bit machine, this
miraculously survives - despite allocating up to two buffers of length 92160
on the stack. The 32-bit machines aren't quite so lucky. Even in the case where
this works, we will either (a) get way more samples than we wanted; or (b) get
about 3840 samples, assuming the timing is pretty good on the machine.

Either way, the calculation being performed is wrong, based on the API users
expectations.

My first inclination was to allocate the buffers on the heap. As it is,
however, there's at least two drawbacks with doing this:
(1) It's a bit complicated, as the size of the buffers may change during the
    lifetime of the audiohook (ew).
(2) The stack is faster (yay); the heap is slower (boo).

Since our calculation is flat out wrong in the first place, this patch fixes
this issue by instead updating the internal sample rate based on the format
passed into the read operation. This causes us to read the correct number of
samples, and has the added benefit of setting the audihook with the right
SLIN format.

Note that this issue was caught by the Asterisk Test Suite as a result of
r432195 in the 13 branch. Because this issue is also theoretically possible
in Asterisk 11, the change is being made here as well.

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432810 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........

Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@413587 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
  
  Add support-level indications to many more source files.
  
  Since we now have tools that scan through the source tree looking for files
  with specific support levels, we need to ensure that every file that is
  a component of a 'core' or 'extended' module (or the main Asterisk binary)
  is explicitly marked with its support level. This patch adds support-level
  indications to many more source files in tree, but avoids adding them to
  third-party libraries that are included in the tree and to source files
  that don't end up involved in Asterisk itself.
........
  r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
  
  Add a script to enable finding source files without support-levels defined.
........

Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In audiohook_read_frame_both, anytime samples are obtained from the read/write
factories a debug statement is logged stating that samples were not obtained
from the factories.  This statement used to only occur if option_debug was
turned on and no samples were obtained; in some refactoring when the
option_debug statement was removed, the "else" clause was removed as well.

This patch makes it so that those debug log statements only occur if the
condition leading up to them actually happened.
........

Merged revisions 364965 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364966 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Everything still compiled after making these changes, so I assume these
whitespace-only changes didn't break anything (and shouldn't have).


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360190 65c4cc65-6c06-0410-ace0-fbb531ad65f3

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356042 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When I made this change initially, I was under the false impression that the
audiohooks structure remained on the channel after all of the hooks had been
detached.  This is not the case, ast ast_read takes care of removing the
audiohooks structure if the lists are empty.
........

Merged revisions 355622 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 355623 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@355624 65c4cc65-6c06-0410-ace0-fbb531ad65f3

of duplicating that logic.
........

Merged revisions 349289 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 349290 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349291 65c4cc65-6c06-0410-ace0-fbb531ad65f3

frames, even after all of the hooks are detached.  This patch short-cicuits us
out before we transcode unnecessarily.
........

Merged revisions 349144 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 349145 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349146 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r316265 | russell | 2011-05-03 14:55:49 -0500 (Tue, 03 May 2011) | 5 lines
  
  Fix a bunch of compiler warnings generated by gcc 4.6.0.
  
  Most of these are -Wunused-but-set-variable, but there were a few others
  mixed in here, as well.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316293 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Fixes null reference bug introduced by audio hook changes that affects various OS distributions.  Thanks David.

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310547 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@310373 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Media Project Phase2: SILK 8khz-24khz, SLINEAR 8khz-192khz, SPEEX 32khz, hd audio ConfBridge, and other stuff

-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
   using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
   and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate.  This allows
   for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
   updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.

-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #18556)
Reported by: kkm

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306258 65c4cc65-6c06-0410-ace0-fbb531ad65f3

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

https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r279949 | dvossel | 2010-07-27 15:57:00 -0500 (Tue, 27 Jul 2010) | 31 lines
  
  Merged revisions 279946 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r279946 | dvossel | 2010-07-27 15:54:32 -0500 (Tue, 27 Jul 2010) | 24 lines
    
    Merged revisions 279945 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines
      
      remove empty audiohook write list on channel
      
      If a channel has an audiohook write list created on it, that
      list stays on the channel until the channel is destroyed.  There
      is no reason to keep that list on the channel if it becomes empty.
      If it is empty that just means we are doing needless translating
      for every ast_read and ast_write.  This patch removes the audiohook
      list from the channel once it is detected to be empty on either a
      read or write.  If a audiohook is added back to the channel after
      this list is destroyed, the list just gets recreated as if it never
      existed to begin with.
      
      (closes issue #17630)
      Reported by: manvirr
      
      Review: https://reviewboard.asterisk.org/r/799/
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279951 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17336)
Reported by: snuffy
Patches:
      doxygen-fixes1.diff uploaded by snuffy (license 35)
Tested by: russell

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268969 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
  
  Fixes crash in audiohook_write_list
  
  The middle_frame in the audiohook_write_list function was
  being freed if a audiohook manipulator returned a failure.
  This is incorrect logic.  This patch resolves this and
  adds detailed descriptions of how this function should work
  and why manipulator failures must be ignored.
  
  (closes issue #17052)
  Reported by: dvossel
  Tested by: dvossel

  (closes issue #16196)
  Reported by: atis
  
  Review: https://reviewboard.asterisk.org/r/623/
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260050 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Added a new manager command to mute/unmute MixMonitor audio on a channel. 
Added a new feature to audiohooks so that you can mute either read / write
(or both) types of frames - this allows for MixMonitor to mute either side
of the conversation without affecting the conversation itself.

(closes issue #16740)
Reported by: jmls

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



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258190 65c4cc65-6c06-0410-ace0-fbb531ad65f3

During the process of removing an audiohook from one channel
and attaching it to another the audiohook's status is updated
to DONE and then back to whatever it was previously.  Typically
updating the status after setting it to DONE is not a good idea
because DONE can trigger unrecoverable audiohook destruction
events... because of this a conditional check was added to
audiohook_update_status to explicitly prevent the audiohook
from ever changing after being set to DONE.  It was this check
that prevented audiohook inherit from work properly though.

Now ast_audiohook_move_by_source is treated as a special exception,
as the audiohook must be returned to its previous status after
attaching it to the new channel.  This is only a safe operation
because the audiohook's lock is held the entire time, otherwise
this could cause trouble.

(closes issue #16522)
Reported by: corruptor



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238635 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(issue #14618)

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230583 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Reviewboard: https://reviewboard.asterisk.org/r/416/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227580 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r224855 | tilghman | 2009-10-20 17:07:11 -0500 (Tue, 20 Oct 2009) | 5 lines
  
  Pay attention to the return value of the manipulate function.
  While this looks like an optimization, it prevents a crash from occurring
  when used with certain audiohook callbacks (diagnosed with SVN trunk,
  backported to 1.4 to keep the source consistent across versions).
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224856 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r197537 | mmichelson | 2009-05-28 09:49:13 -0500 (Thu, 28 May 2009) | 21 lines
  
  Add flags to chanspy audiohook so that audio stays in sync.
  
  There are two flags being added to the chanspy audiohook here. One
  is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set,
  we ensure that the read and write slinfactories on the audiohook do
  not skew beyond a certain tolerance.
  
  In addition, there is a new audiohook flag added here,
  AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for
  a slinfactory to build up a substantial amount of audio before 
  flushing it. For this particular issue, this means that the person 
  spying on the call will hear the conversations in real time with very 
  little delay in the audio.
  
  (closes issue #13745)
  Reported by: geoffs
  Patches:
        13745.patch uploaded by mmichelson (license 60)
  Tested by: snblitz
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197543 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191419 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187599 65c4cc65-6c06-0410-ace0-fbb531ad65f3

audio_audiohook_write_list() did not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz.  the sample size is now updated after translating to reflect this possibility.  This caused the audio on the receiving end to sound terrible.  Thanks to jcolp and mmichelson for helping me work this out.

(issue AST-197)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186379 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r185196 | file | 2009-03-31 11:06:39 -0300 (Tue, 31 Mar 2009) | 8 lines
  
  Fix crash when moving audiohooks between channels.
  
  Handle the scenario where we are called to move audiohooks between channels
  and the source channel does not actually have any on it.
  
  (closes issue #14734)
  Reported by: corruptor
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@185197 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #14574)
Reported by: KNK
Patches:
      audiohook_volume_fix.diff uploaded by KNK (license 545)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@179291 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Always detach and destroy the whisper and barge audiohooks. Additionally also allow an audiohook to be detached if it has not been attached.
(closes issue #14414)
Reported by: bluecrow76


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173902 65c4cc65-6c06-0410-ace0-fbb531ad65f3

I don't know how this crept back in when I had already
fixed it earlier



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166162 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel 
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor 
continue recording the call even after the transfer
has completed.

It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.

(closes issue #13538)
Reported by: mbit
Patches:
      13538.patch uploaded by putnopvut (license 60)
	  Tested by: putnopvut

Review: http://reviewboard.digium.com/r/102/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166092 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines

Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.

Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149205 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137082 65c4cc65-6c06-0410-ace0-fbb531ad65f3

make datastore creation and destruction a generic API since it is not really channel related, and add the ability to add/find/remove datastores to manager sessions


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135680 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130634 | russell | 2008-07-14 05:38:14 -0500 (Mon, 14 Jul 2008) | 2 lines

Bump up the debug level for a message.

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130635 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130236 | mmichelson | 2008-07-11 15:03:23 -0500 (Fri, 11 Jul 2008) | 3 lines

Remove redundant logic


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130237 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r130173 | mmichelson | 2008-07-11 14:13:29 -0500 (Fri, 11 Jul 2008) | 7 lines

Fix a typo in audiohook_read_frame_both.

While this change has not been proven to fix any
specific issue, it is incorrect and could cause
unforeseen problems.


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130174 65c4cc65-6c06-0410-ace0-fbb531ad65f3