[Freeswitch-users] Choppy sound with PCMU

[Michael Jerris]

First off, maybe this conversation is better suited to the dev list, and second off, the current setup of where we do timers, where we poll, polling frequency and architecture is the result of 4+ years of ongoing testing and optimization.  We have tried all different methods throughout.  Sometimes what we found to be most efficient is not what we thought at first would be, but testing showed otherwise.  We have always optimized the general case as to if there are many calls, and no suggestion would be implemented that hurts this case.  That being said, if you could really come up with a way for this to be more efficient in any case, without sacrificing performance int he other cases, you are able to prove this with extensive test results, and you are able to prove that it does not impact for example call quality in any of the hundreds of edge cases that have led us to the point we are now, then we may be interested in taking such a patch.  

Mike



On Dec 2, 2009, at 11:58 PM, eaf wrote:

> 
> As I see it, switch_cond_next() currently is just a do_sleep(1000). Yes, it
> could be mapped to a 1ms timer, but "#define DISABLE_1MS_COND" overrides
> that.
> 
> Yeah, there is a global timestamp... It's easy to workaround that for RTP
> who calls switch_micro_time_now()... But if somebody accesses
> runtime.timestamp directly, it's gonna be tough to grep for that. If only
> this was C++...
> 
> I'll play around. Never liked polling too much. Never could've guessed that
> polling could be so useful for scalability ;) My naive implementation
> would've pulled timestamp via system calls and would've done sleeping by
> passing exact interval to select() instead of syncing with a pacing thread.
> Which would be dead-quiet at idle time, but, of course, would stop scaling
> at some point due to excessive number of system calls.
> 
> Thanks.
> 
> 
> Michael Jerris wrote:
>> 
>> In short.  No, you can not for many reasons. The milisecond tic is  
>> used throughout the code even when there is not any calls up.  You can  
>> grep for switch_cond_next if you would like to see where but it is  
>> required to keep our global timestamp and for pacing the scheduler  
>> among other services that run all the time.
>> 
>> Mike
>> 
>> On Dec 2, 2009, at 7:31 PM, eaf <erandr-junk at usa.net> wrote:
>> 
>>> 
>>> Can I reduce resolution of that timer thread 10 times? I mean, I  
>>> glanced
>>> through the code, and see that among others (are there others?) RTP  
>>> and IVR
>>> set up their timers that are subsequently managed by this thread.  
>>> RTP timers
>>> should be eliminated by that setting you've suggested. IVR timers  
>>> are set at
>>> 20ms... So, if the thread is set to wake up every 10ms instead of  
>>> 1ms it
>>> should be able to wake up those IVR timers just fine. Right?
>>> 
>>> That's a cool design to have one dedicated thread that maintains  
>>> accurate
>>> timing and then broadcasts via condition variables to hundreds of  
>>> other
>>> threads events that they can register for. I'm sure it's one of the  
>>> reasons
>>> why FS scales so much better than Asterisk. But for poor low-end  
>>> setups that
>>> sit in the closet, eat only 6W of power and hardly ever run more  
>>> than two
>>> calls at the same time, can I hack it somehow to be more UNIX- 
>>> friendly? I.e.
>>> make it stuck in select() or recv() when there is nothing to do, call
>>> clock_gettime() right from the thread that wants and when it wants  
>>> to know
>>> current time?
>>> 
>>> Say, what if that thread is made to suspend on a condition variable  
>>> in case
>>> if there are no timers registered in TIMER_MATRIX? Then, if some other
>>> thread comes up and adds its timer into the matrix, it could wake up  
>>> the
>>> timer thread and enjoy accurate timing as needed, on demand? And in- 
>>> between
>>> the calls, when there is no RTP or IVR, it will all go silent? I mean,
>>> sitting on a wait queue in the kernel is way better than go back and  
>>> forth
>>> incrementing counters that nobody even needs at the moment?
>>> 
>>> 
>>> Anthony Minessale-2 wrote:
>>>> 
>>>> idle is a 4 letter word to a realtime application.
>>>> 
>>>> The core keeps a single high-priority thread to keep 1ms timing and
>>>> expands
>>>> that broadcasting
>>>> to hundreds or thousand of threads who need accurate timing.
>>>> 
>>>> Your choppy audio is caused by linksys lying about the packet len  
>>>> that
>>>> it's
>>>> using and we set our timer
>>>> to the wrong speed.
>>>> 
>>>> 
>>> 
>>> -- 
>>> View this message in context:
>>> http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26619085.html
>>> Sent from the Freeswitch-users mailing list archive at Nabble.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
>> 
>> _______________________________________________
>> 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
>> 
>> 
> 
> -- 
> View this message in context: http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26621005.html
> Sent from the Freeswitch-users mailing list archive at Nabble.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