| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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: http://svn.digium.com/svn/asterisk/branches/1.8@279949 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@260050 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@258190 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@238635 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #14618)
Review: https://reviewboard.asterisk.org/r/434/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@230583 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reviewboard: https://reviewboard.asterisk.org/r/416/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@227580 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@197543 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Copied from my review board description:
This is a continuation of the API changes documentation started for describing
changes between releases. Most of the API changes were pretty simple needing
only to be brought to attention via the new "Asterisk API Changes" list.
However, if you see anything that needs further explanation feel free to
supplement what is there. The current method of documenting is to add (in the
header file): \version <ver number> <description of changes> and then to add
the function to the change list in doxyref.h on the AstAPIChanges page. I also
made sure all the functions that were newly added were tagged with \since
1.6.1. I think this is a good habit to start both for the historical aspect as
well as for the future ability to easily add a "New Asterisk API" page.
Review: http://reviewboard.digium.com/r/190/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@180719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@166092 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@149205 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and denoising to a channel, AGC() and DENOISE(). Also included, is a change
to the audiohook API to add a new function (ast_audiohook_remove) that can
remove an audiohook from a channel before it is detached.
This code is based on a contribution from Switchvox.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@114926 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
developers to adjust the volume on a channel.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@110542 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r108083 | file | 2008-03-12 15:26:37 -0300 (Wed, 12 Mar 2008) | 4 lines
Add a trigger mode that triggers on both read and write. The actual function that returns the combined audio frame though will wait until both sides have fed in audio, or until one side stops (such as the case when you call Wait).
(closes issue #11945)
Reported by: xheliox
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@108084 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This works in much the same way as the automonitor, except that instead of using the monitor
app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF
sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor.
This patch also introduces some new API calls to the audiohooks code for searching for an audiohook
by type and for searching for a running audiohook by type.
Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to
be committed.
(closes issue #10185, reported and patched by xmarksthespot)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@90388 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that a channel doesn't need to be locked before calling a certain function.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@90141 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89519 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Closes issue #10654, patch by snuffy
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@81560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
functions. As inline functions, the lock debug information will show that
these are always locked in audiohooks.h instead of the file where the lock was
actually acquired.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@81264 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
listen and manipulate the audio going through a channel.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@78649 f38db490-d61c-443f-a65b-d21fe96a405b
|
