[asterisk-dev] [Code Review] 3379: ARI: Make bridges/{bridgeId}/play queue sound files if sounds are already playing on the bridge instead of playing them simultaneously as they are called

[Jonathan Rose]

> On March 27, 2014, 4:20 p.m., Matt Jordan wrote:
> > /branches/12/res/res_ari_bridges.c, lines 950-956
> > <https://reviewboard.asterisk.org/r/3379/diff/4/?file=56651#file56651line950>
> >
> >     If it isn't already noted, this needs to be in the CHANGES file.
> >     
> >

Upon examining the changes file I realized that I hadn't implemented the path version for playbackID. Rats.
That'll be in the next update.

I'm adding it to the CHANGES file. It's more of an amendment since 12.2 already has a changes note for this with channels/play


> On March 27, 2014, 4:20 p.m., Matt Jordan wrote:
> > /branches/12/res/res_stasis.c, lines 632-634
> > <https://reviewboard.asterisk.org/r/3379/diff/4/?file=56652#file56652line632>
> >
> >     This is a global ao2 container. How are we able to insert an item into it without locking it?

This might be an issue for the MOH channel wrappers as well


- Jonathan


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


On March 25, 2014, 5: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, 5: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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140328/ed37b3db/attachment-0001.html>