> On March 27, 2014, 10:14 p.m., Mark Michelson wrote: > > /branches/12/res/ari/resource_bridges.c, lines 323-329 > > <https://reviewboard.asterisk.org/r/3379/diff/4/?file=56650#file56650line323> > > > > ari_bridges_play_found() calls this with the control locked, but > > ari_bridges_play_new() calls this with the control not locked. I suspect > > you do not want the lock held during this.
Actually, after looking further, you probably *do* mean to have the lock held when called from ari_bridges_play_found(). I still think it should be consistent though. - Mark ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3379/#review11404 ----------------------------------------------------------- On March 25, 2014, 10:14 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3379/ > ----------------------------------------------------------- > > (Updated March 25, 2014, 10: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 > > 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
