useless cpu consumes during call in hold state

[GoogleCodeExporter]

When a call is put in an hold state or, for example the microphone is muted, 
the rtp sender thread and rtp receiver thread entered in an active loop that 
each second control values of some variables and tipically continue this loop 
until the call state does not change.
I think that this it is quite useless and consumes only cpu cycles. I want to 
propose a simple change that introduces 2 semaphore in order to suspend that 
threads, and make it possible to suspend these threads until necessary, 
without consuming resources.

Tell me what you think about that.
(I made some test and on my htc magic works well)

Original issue reported on code.google.com by f.crisci...@gmail.com on 30 Jan 2010 at 7:22

Attachments:

• patch.diff

[GoogleCodeExporter]

This is absolutely unnecessary given the idle capabilities of the kernel. you 
will not 
notice any measureable difference with your patch.

Original comment by pmerl...@googlemail.com on 30 Jan 2010 at 7:44

• Changed state: Invalid

[GoogleCodeExporter]

I am not so sure this is unnecessary.

While the existing code does work, it manages a HOLD condition with an active 
loop,
with two threads (RtpStreamReceiver and RtpStreamSender) cycling once every 
1000ms,
waking up, checking if the HOLD condition still exists, and then going back to 
sleep.
 The Sender thread even turns the Audio back on and off again every cycle.  This
seems to me to be very inefficient and inelegant.  Turning on the Audio just to 
turn
it off again is not a good move.  These loops will require two thread context
switches as well as the Audio on/off switch once a second, which will be 
detrimental
to the performance of other processes.  On top of that, due to the 1000ms loop, 
when
the HOLD condition is removed, it can be up to 1 sec before the call actually 
resumes.

This patch replaces all that with a much cleaner mechanism that stops the two 
threads
entirely and only restarts them once the HOLD condition is released.  The Audio 
is no
longer turned on and off every cycle.  They restart immediately once the HOLD
condition is removed.  This is all together much less expensive on the system 
as a
whole and more cleanly achieves what is desired.

I have proposed a slight change to the patch in email back to the author to 
further
simplify it.

But I think it would be worth including this idea.

Original comment by jropal...@gmail.com on 31 Jan 2010 at 8:23