[Freeswitch-users] Playback race condition

Hynek Cihlar hynek.cihlar at gmail.com
Sat Nov 19 11:12:41 MSK 2011


Two reasons I am not using api in this case.

1. Performance
2. Doesn't seem to work

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.

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).

Hynek



On Sat, Nov 19, 2011 at 8:48 AM, Peter Olsson <
peter.olsson at visionutveckling.se> wrote:

> 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&#246;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!
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111119/02936817/attachment-0001.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list