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@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