[Home]

Summary:ASTERISK-24573: [patch]Out of sync conversation recording when divided in multiple recordings
Reporter:Nuno Borges (nerbos)Labels:
Date Opened:2014-12-01 08:33:38.000-0600Date Closed:2014-12-06 12:21:51.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_monitor
Versions:SVN 1.8.32.1 11.14.1 12.7.1 13.0.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 24573.patch
Description:In order to avoid big recording files we have decided to segment the recording in bulks of 5 minutes, issuing a stop and a start recording via AMI. We started to notice that some of the segments get the voice out of sync, when at the time of the recording the voice streaming was correct.
Comments:By: Nuno Borges (nerbos) 2014-12-01 08:35:23.604-0600

Resetting the outsmpl and insmpl whenever a recording is started solved this issue
By: Matt Jordan (mjordan) 2014-12-02 13:53:32.020-0600

Two points:

# 1.8 is no longer supported for bug fixes. For this patch to be considered, it will need to be written against Asterisk 11. Since the channel API was opaquified, that will require some minor tweaks to the patch.
# I don't think the issue described here adequately describes the need for the patch. Can you explain why this fixed the issue?

Specifically, I'm concerned about the impact of this patch on the normal frame writing that occurs in {{channel.c}}. Setting both to {{0}} would ensure that no jump occurs when attempting to perform a seek in the stream, and I'm not sure if that's a good thing or a bad thing.

{code}
#ifndef MONITOR_CONSTANT_DELAY
int jump = ast_channel_insmpl(chan) - ast_channel_outsmpl(chan) - 4 * cur->samples;
if (jump >= 0) {
jump = calc_monitor_jump((ast_channel_insmpl(chan) - ast_channel_outsmpl(chan)), ast_format_rate(&f->subclass.format), ast_format_rate(&ast_channel_monitor(chan)->read_stream->fmt->format));
if (ast_seekstream(ast_channel_monitor(chan)->write_stream, jump, SEEK_FORCECUR) == -1) {
ast_log(LOG_WARNING, "Failed to perform seek in monitoring write stream, synchronization between the files may be broken\n");
}
ast_channel_outsmpl_set(chan, ast_channel_outsmpl(chan) + (ast_channel_insmpl(chan) - ast_channel_outsmpl(chan)) + cur->samples);
} else {
ast_channel_outsmpl_set(chan, ast_channel_outsmpl(chan) + cur->samples);
}
#else
int jump = calc_monitor_jump((ast_channel_insmpl(chan) - ast_channel_outsmpl(chan)), ast_format_rate(f->subclass.codec), ast_format_rate(ast_channel_monitor(chan)->read_stream->fmt->format));
if (jump - MONITOR_DELAY >= 0) {
if (ast_seekstream(ast_channel_monitor(chan)->write_stream, jump - cur->samples, SEEK_FORCECUR) == -1) {
ast_log(LOG_WARNING, "Failed to perform seek in monitoring write stream, synchronization between the files may be broken\n");
}
ast_channel_outsmpl_set(chan, ast_channel_outsmpl(chan) + ast_channel_insmpl(chan) - ast_channel_outsmpl(chan));
} else {
ast_channel_outsmpl_set(chan, ast_channel_outsmpl(chan) + cur->samples);
}
#endif
{code}
By: Nuno Borges (nerbos) 2014-12-03 08:57:13.127-0600

Hi,

1) I have changed the patch to asterisk 13.0.1.

2) The problem here is that by using the old outsmpl and insmpl may create bad jumps on the newly created write/read stream, so by resetting both to zero will have the same behavior as it was the first recording, since they should start with the value 0 (memory initialization puts both values with 0, i hope, since i don't see these values being initialized)

Best regards.
By: Matt Jordan (mjordan) 2014-12-06 12:12:15.187-0600

That seems correct to me. Looking at the history of the code in {{channel.c}}, it doesn't appear like resetting the sample counts to 0 on a complete Monitor stop/start would cause any inadvertent jumps - which is actually what is occurring when the sample counts aren't reset.