<div>Two reasons I am not using api in this case. </div><div><br></div><div>1. Performance</div><div>2. Doesn't seem to work</div><div><br></div><div>1. Blocking issuing the command will eventually reduce the system throughput. Agree this is only a potential theoretical problem and I haven't gotten into production where I could get the actual results.</div>
<div><br></div><div>2. When issuing api uuid_playback and api uuid_break right after, I'm always getting an error response from the uuid_break. The ESL message body is "-ERR no reply". Nothing in the logs (no idea which log type/level will could generate other useful info).</div>
<br clear="all">Hynek<br><br>
<br><br><div class="gmail_quote">On Sat, Nov 19, 2011 at 8:48 AM, Peter Olsson <span dir="ltr"><<a href="mailto:peter.olsson@visionutveckling.se">peter.olsson@visionutveckling.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Since you're using bgapi, it's impossible to guarantee that uuid_broadcast has actually executed before you exeute uuid_break (they will be executed in two different threads). You will have to do this in a more controlled way (wait for events to show up etc.). And also, do you really need to use bgapi all the time? I'm not sure how uuid_broadcast is handled, but uuid_break is totally safe to use without bgapi, since it will just update a flag and then return immediately. I think uuid_broadcast will do the same thing - so getting rid of bgapi should be a good ebnough solution.<br>
<br>
/Peter<br>
________________________________________<br>
Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a>]<br>
Skickat: den 19 november 2011 08:31<br>
Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Playback race condition<br>
<div class="im"><br>
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.<br>
<br>
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?<br>
<br>
Thanks!<br>
Hynek<br>
<br>
<br>
<br>
</div><div class="im">On Fri, Nov 18, 2011 at 6:46 PM, Hynek Cihlar <<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a>>> wrote:<br>
Hello all,<br>
<br>
I got on shaky grounds issuing commands to Freeswitch over ESL.<br>
<br>
For example, issuing the following commands close enough (on my system at around 100 ms and less) causes troubles.<br>
<br>
bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 playback::tone_stream://%(150,4000,425);loops=-1<br>
<100ms appart<br>
bgapi uuid_break 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 all<br>
previous playback is not stopped, the following is queued (not played)<br>
bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 playback::tone_stream://%(1000,4000,425);loops=-1<br>
<br>
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.<br>
<br>
Any ideas?<br>
<br>
<br>
Hynek<br>
<br>
<br>
</div>!DSPAM:4ec75b5732763454765634!<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br>