Age | Commit message (Collapse) | Author | Files | Lines |
|
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.4@279945 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@260049 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@224855 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@197537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ast_translate.
audio_audiohook_write_list() does not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz. While no 16kz codecs are supported in 1.4 at the moment, this will save headaches in the future if they ever are. the sample size is now updated after translating to reflect this possibility. Thanks to jcolp and mmichelson for helping me work this out.
(issue AST-197)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@188287 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@185196 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13538)
Reported by: mbit
Patches:
13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166157 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@149204 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130634 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130236 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
While this change has not been proven to fix any
specific issue, it is incorrect and could cause
unforeseen problems.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130173 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute.
(closes issue #12296)
Reported by: jvandal
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@113296 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@108083 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
take care of current known spy issues.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98972 f38db490-d61c-443f-a65b-d21fe96a405b
|