----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3379/#review11438 -----------------------------------------------------------
/branches/12/res/ari/resource_bridges.c <https://reviewboard.asterisk.org/r/3379/#comment21107> Before, if a control were queued between stasis_app_control_execute_until_exhausted and the ast_hangup, this would result in a failed queue since the the command would fail to be queued on the outgoing channel which would still be found when consulting the bridge playback channel wrapper container. Now if that operation fails, additional passes will be made until either a channel that isn't dying is returned from the playback wrapper or else there is no channel in the bridge playback wrapper, which will result in the new channel creation method being used instead. /branches/12/res/res_stasis.c <https://reviewboard.asterisk.org/r/3379/#comment21106> If command_count here is 0 and a new command is added before ao2_lock is added, control_command_count will be greater than 0 and the loop will make another pass (which will mean the new command will get dispatched). This addresses one of the concerns mmichelson raised. - Jonathan Rose On March 28, 2014, 3:14 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3379/ > ----------------------------------------------------------- > > (Updated March 28, 2014, 3:14 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-22677 > https://issues.asterisk.org/jira/browse/ASTERISK-22677 > > > Repository: Asterisk > > > Description > ------- > > Previously, if you played an audio file and then played another before the > first finished, the second audio file would start playing immediately as it > was called overlapping the previous sound. Apparently people don't like that. > This patch changes that behavior so that the sound will be queued at the end > of any existing controls if they are running. > > > Diffs > ----- > > /branches/12/rest-api/api-docs/bridges.json 411187 > /branches/12/res/stasis/control.c 411187 > /branches/12/res/stasis/control.h 411187 > /branches/12/res/res_stasis_playback.c 411187 > /branches/12/res/res_stasis.c 411187 > /branches/12/res/res_ari_bridges.c 411187 > /branches/12/res/ari/resource_bridges.c 411187 > /branches/12/res/ari/resource_bridges.h 411187 > /branches/12/include/asterisk/stasis_app.h 411187 > /branches/12/CHANGES 411187 > > Diff: https://reviewboard.asterisk.org/r/3379/diff/ > > > Testing > ------- > > Tested for playback channel wrapper leaks, tested to make sure control > objects were being destroyed when they fell out of use. Tested playing of a > single file. Tested playing of multiple files in a row. Tested playing of > multiple files in a row and then after a sequence finished, playing > additional files so that new channels would have to be created. Tested > playing sounds right as other sounds were concluding. I wasn't able to break > it (although I wouldn't be surprised if there is a possible condition where > you can grab a control as it is finishing up its queue and then attempting to > add a sound to a finished queue causing the playback to fail. I don't think > this would break things in a profound way, it just might possibly make one > sound fail to queue under extremely unlikely conditions). > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
