[Freeswitch-users] Choppy sound with PCMU

[eaf]

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.