FS#6316 - Avoid full cpu boost during radio recordings

Attached to Project: Rockbox
Opened by Toni (ahellmann) - Saturday, 11 November 2006, 18:43 GMT
Task Type Patches
Category Recording
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Avoid full cpu boost during radio recordings (on H1xx and others?)

Entering the recording screen via radio menu leads to cpu full boost recording.
This unnecessary drains the battery during recordings.

Reason for full boost: The thread.c module only unboosts when all threads are sleeping.
Unfortunately the encoder codecs never sleep.

But this works fine, if the latency between the last trigger_cpu_boost() and
loading the codecs is big enough to do the unboost before the encoder codec has been
loaded. The rec_set_source() in recording.c gives this latency if the source is REALLY

But when starting a recording from the radio screen, the latency is smaller, because
there is no real recording source change. So the new encoder thread will be started
(and never sleep) before thread.c stops boosting.

To solve the described problem, this patch applies a small sleep() to the encoders, so
that thread.c gets the chance to do the unboost even after the encoders have been
This task depends upon

Closed by  Michael Sevakis (MikeS)
Friday, 01 December 2006, 15:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  Original reporter reports problem fixed.
Comment by Michael Sevakis (MikeS) - Friday, 01 December 2006, 01:41 GMT
Something must have fixed this because I don't observe 100% boost on any encoder entering through the radio screen even if the HD doesn't need spinup. The most boost I get is 12%-13% for wavpack_enc at 44.1 stereo on H120 (boost ratio displayed in rec screen and prerecording only). x5 exhibits no symptoms either. Perhaps there's a clue in here as to why a stray boost is left after boot when voice is enabled?
Comment by Toni (ahellmann) - Friday, 01 December 2006, 13:25 GMT
I checked with 20061201 build. The removing of SCHEDULER_BOOST_CONTROL seems to have fixed this issue. No problems here anymore.