[asterisk-dev] [Code Review] In-queue MOH stops after a periodic announcement

[jrose]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1328/#review3919
-----------------------------------------------------------


Just to explain the bug a little more clearly, in case anyone is curious...

This occurs when music on hold gets interrupted by app_queue to play the various intermittent speeches about how close you are to getting answered and that usual stuff.  If music on hold is near the end of a music on hold sound file as the interruption occurs, what happens is music on hold is stopped, the interruption occurs, and then music on hold is told to pick up at an offset based on how far into the song it would be if the interruption hadn't occured.

So basically 
new_start = end_of_last_playback + time_of_interruption

If this new_start value happens to point to an offset that is after the end of the song file, the queue playback gets stuck, and rather than simply going on to the next song from there, music on hold won't start playing again.  The interruptions still occur, and after each interruption is finished, it will again try to start music on hold at the location of failure and fail again.

This patch fixes that by detecting when failures from that occur and then doing a second seek at a frame before the end of the file, and that has fixed the problem as I have observed it.

I suspect that the reason this affects g722 rather than the other codecs I've tried is because the seek value seeks by byte or something of fixed size while g722, being an HD format, has a larger frame size.

- jrose


On July 21, 2011, 2:56 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1328/
> -----------------------------------------------------------
> 
> (Updated July 21, 2011, 2:56 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> With a g722 call connected to the queue, after listening up to the end of the second song, the music on hold will be interrupted by a generic Allison message about representatives being busy and once the message concludes, the following error will show up:
> 
> WARNING[16606]: format_pcm.c:140 pcm_seek: offset too large 2303040, truncating to 2232088
> 
> and at this point, the music will not resume and interruptions will continue as normal. That message will continue to play with those same values after each interruption.
> 
> Note: This was only experienced with G.722 out of several codecs tested, but could conceivably happen with other codecs.
> 
> 
> This addresses bug ASTERISK-18077.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18077
> 
> 
> Diffs
> -----
> 
>   trunk/res/res_musiconhold.c 329103 
> 
> Diff: https://reviewboard.asterisk.org/r/1328/diff
> 
> 
> Testing
> -------
> 
> Confirmed that the patch fixes the issue described.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110721/2c562bdc/attachment.htm>