[Freeswitch-users] Playback race condition

[Hynek Cihlar]

As a workaround I put a synthetic a delay between the start and stop of the
playback. I wouldn't want to keep this solution however since it blocks one
of the worker threads (decreasing overall system throughput) and second, I
really don't know what the synthetic delay should be or whether it could
differ during different conditions like during a high load.

Was anybody facing similar problem? How did you solve it? Am I using the
API wrong and is there another way to invoke playback/stop?

Thanks!
Hynek



On Fri, Nov 18, 2011 at 6:46 PM, Hynek Cihlar <hynek.cihlar at gmail.com>wrote:

> Hello all,
>
> I got on shaky grounds issuing commands to Freeswitch over ESL.
>
> For example, issuing the following commands close enough (on my system at
> around 100 ms and less) causes troubles.
>
> *bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2
> playback::tone_stream://%(150,4000,425);loops=-1*
> *<100ms appart*
> *bgapi uuid_break 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 all*
> *previous playback is not stopped, the following is queued (not played)*
> *bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2
> playback::tone_stream://%(1000,4000,425);loops=-1*
>
> It looks like the first tone playback is not properly initialized when the
> break arrives. Waiting for the start of the first tone playback (waiting
> for the right event) is not a solution, I don't want the tone to be played
> at all if the events come this close.
>
> Any ideas?
>
>
> Hynek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111119/3ed25e41/attachment.html