On Mon, Jul 06, 2009 at 03:44:02PM +0300, Fotos Georgiadis wrote:
>
> Recorded calls using MixMonitor() result in data loss,
> since the recordings are (recorded and) played back at high speed.
>
> You won't know of this data loss unless you try to recover
> one of the recordings (and then it's too late).
>
> Fixed upstream (https://issues.asterisk.org/view.php?id=13005)
This issue appears at first glance (from looking at the bug report) to
be specific to 1.4. That is: to the version in Lenny, and thus not to
apply to the version in Squeeze.
I attach the patch from the bug report. It applies to our Lenny package.
I have not checked any further.
--
Tzafrir Cohen
icq#16849755 jabber:[email protected]
+972-50-7952406 mailto:[email protected]
http://www.xorcom.com iax:[email protected]/tzafrir
commit 4f7500247c2eab9642b08afbb1fd609b52224fbf
Author: mmichelson <mmichel...@f38db490-d61c-443f-a65b-d21fe96a405b>
Date: Tue Oct 14 23:00:01 2008 +0000
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/branches/1...@149204 f38db490-d61c-443f-a65b-d21fe96a405b
diff --git a/include/asterisk/audiohook.h b/include/asterisk/audiohook.h
index 5f79d83..3375906 100644
--- a/include/asterisk/audiohook.h
+++ b/include/asterisk/audiohook.h
@@ -56,6 +56,8 @@ enum ast_audiohook_flags {
AST_AUDIOHOOK_TRIGGER_SYNC = (1 << 2), /*!< Audiohook wants to be triggered when both sides have combined audio available */
};
+#define AST_AUDIOHOOK_SYNC_TOLERANCE 100 /*< Tolerance in milliseconds for audiohooks synchronization */
+
struct ast_audiohook;
/*! \brief Callback function for manipulate audiohook type
diff --git a/main/audiohook.c b/main/audiohook.c
index 809c176..f15395b 100644
--- a/main/audiohook.c
+++ b/main/audiohook.c
@@ -130,12 +130,19 @@ int ast_audiohook_write_frame(struct ast_audiohook *audiohook, enum ast_audiohoo
struct ast_slinfactory *factory = (direction == AST_AUDIOHOOK_DIRECTION_READ ? &audiohook->read_factory : &audiohook->write_factory);
struct ast_slinfactory *other_factory = (direction == AST_AUDIOHOOK_DIRECTION_READ ? &audiohook->write_factory : &audiohook->read_factory);
struct timeval *time = (direction == AST_AUDIOHOOK_DIRECTION_READ ? &audiohook->read_time : &audiohook->write_time), previous_time = *time;
+ int our_factory_ms;
+ int other_factory_samples;
+ int other_factory_ms;
/* Update last feeding time to be current */
*time = ast_tvnow();
+ our_factory_ms = ast_tvdiff_ms(*time, previous_time) + (ast_slinfactory_available(factory) / 8);
+ other_factory_samples = ast_slinfactory_available(other_factory);
+ other_factory_ms = other_factory_samples / 8;
+
/* If we are using a sync trigger and this factory suddenly got audio fed in after a lapse, then flush both factories to ensure they remain in sync */
- if (ast_test_flag(audiohook, AST_AUDIOHOOK_TRIGGER_SYNC) && ast_slinfactory_available(other_factory) && (ast_tvdiff_ms(*time, previous_time) > (ast_slinfactory_available(other_factory) / 8))) {
+ if (ast_test_flag(audiohook, AST_AUDIOHOOK_TRIGGER_SYNC) && other_factory_samples && (our_factory_ms - other_factory_ms > AST_AUDIOHOOK_SYNC_TOLERANCE)) {
if (option_debug)
ast_log(LOG_DEBUG, "Flushing audiohook %p so it remains in sync\n", audiohook);
ast_slinfactory_flush(factory);
