As you may have seen from a recent submission, it was recently found that there was a consistent delay when adding a channel into the Stasis application.

After the Stasis application is launched on a channel, it goes into an exec loop waiting for new commands and/or application changes.  To prevent this loop from spinning constantly, the loop waits on the channel for up to 200 ms during each iteration.  This means that if the channel has no activity (such as audio) it will wait for 200 ms. Any new commands added to the queue during this time must therefore wait before being processed.

This can potentially cause noticeable gaps in audio during call setup via ARI – particularly if building a call from multiple channels in series.

So to address this, when a new ARI command is issued for a channel while in this wait, the sleeping exec loop will now be signaled to wake and continue processing.  This should break out of the sleep and allow the queued commands to be processed without delay.

The results of this can be immediately seen on a channel entering the stasis application.  While there was previously a delay when bridging the channel, you should now see the channel bridged almost immediately.

Hopefully this translates into better real-world performance for your ARI applications!