[Freeswitch-users] Choppy sound with PCMU

[eaf]

Oh, you mean giving FS higher priority? Yeah, as a last resort I'll do that.
At the moment, I hope it won't be necessary as I can make those "hyper"
threads behave, and will see how that goes first. I see where your
implementation could be coming from. There is a queue of SQL queries in
sofia.c processed by the worker thread. There are only two pop functions
available in APR: queue_pop() and queue_trypop(), so alas no option with a
timeout here. You don't want to block the thread in pop() indefinitely
because you chose that same worker needs to do ireg and gw processing once
in a while (separated by tens or hundreds of seconds, btw). You also want to
be able to detect shutdown condition so that the worker doesn't hold up
profile thread. So you chose to poll for events every millisecond instead of
just creating an apr_thread_cond_t for resource friendly signalling.

I agree that the timer thread philosophy is great and was the right choice
for scaling, but I just don't comprehend responses to things like these
other SQL or sofia worker threads. Did somebody even remotely acknowledge
that busy loops at least in those areas that I showed may probably be a bad
idea and could've been eliminated? I've heard suggestions to bump up
priority, I've heard that the code was perfect already, that it's the result
of 4-year effort, that I am arrogant, don't listen and don't understand
squat.

I'm sorry if I gave you impression that I was looking for the bad parts in
the software. I apologized for that already. All I wanted was to have
constructive conversation, perhaps I'm not too good at it. Code is already
perfect according to you? Fine with me.


Anthony Minessale-2 wrote:
> 
> no,
> 
> I mean the one after that that you must have completely skipped with a
> command line option to try and a param to set in the config. It somewhat
> annoys me for taking the time to compose it now.  I wrote all of the code
> you are talking about myself and I was trying to give you some
> suggestions....
> 
> Well, actually,  you did answer my question about the platform so you must
> have seen it.....
> 
> The loops are not the cause of that migration message, something wrong
> with
> the hardware or the kernel is.
> Another guy just told you he does not see that problem on the same exact
> hardware.
> 
> Even if you have a point about the sql threads, you could make a patch to
> slow them down but you cant slow down too much or you will not be able to
> handle 400 cps all asking to send updates to transactions in batches of
> thousands of sql stmts.  Every line of that code is carefully designed so
> I
> don't know what else to tell you but to stop being so arrogant and re-read
> this thread for all the advice you have totally ignored.  I started out
> trying to help you but I have a lot of work to do.  I thoroughly explained
> it to you and you are choosing to ignore me so I guess I'm done.
> You can do whatever you want with your working copy, i'll see you in 3 or
> 4
> years when you get up to speed with the rest of us........
> 
> 

-- 
View this message in context: http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26633739.html
Sent from the Freeswitch-users mailing list archive at Nabble.com.