[Freeswitch-users] Playback race condition

[Peter Olsson]

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.

/Peter
________________________________________
Från: freeswitch-users-bounces at lists.freeswitch.org [freeswitch-users-bounces at lists.freeswitch.org] för Hynek Cihlar [hynek.cihlar at gmail.com]
Skickat: den 19 november 2011 08:31
Till: FreeSWITCH Users Help
Ämne: Re: [Freeswitch-users] Playback race condition

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<mailto: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


!DSPAM:4ec75b5732763454765634!