Hi.

I have a problem with MediaPlayer on my HTC Hero.  When I set it to
decrypt & play a local file in the background, it starts skipping
after a minute or two, even though I have aquired the
PARTIAL_WAKE_LOCK.  This only happens when the phone is running on
battery:  I'm unable to reproduce this with the USB cable plugged in.
In addition, this only happens when I leave the phone to play.  If I'm
using another app actively, the music never skips.

Does the CPU lower its frequency when running on battery?  The logs
look the same whether I'm playing on battery or not.  Also, if I

Best regards,
Henrik

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

On 25 apr, 12:08, henrik <henrik.aron...@gmail.com> wrote:

The weird thing is, the problem goes away if I use
SCREEN_DIM_WAKE_LOCK instead.  But I really don't want to drain my
users' batteries needlessly.

Henrik

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

With respect to "Does the CPU lower its frequency when running on
battery?", that is up to the device manufacturer and probably cannot be
stated for Android as a whole. It is eminently possible that on your
edition of the Hero the CPU drops when the screen is not on.

If you have one media file (decrypted) playing while you are decrypting
another, consider reducing the the priority of the decryption thread:

Thread.currentThread().setPriority(Thread.MIN_PRIORITY+1);

And perhaps, if possible, toss a yield() in periodically during the
decryption itself, if you aren't just passing this over to some API call:

Thread.yield();

That way, if the skip is caused by slower CPU speeds, you'll be doing
more to let MediaPlayer have "first dibs" on what CPU there is.

If you can reproduce the skipping problem even without your decryption
thread running -- if it skips on ordinary files -- see if the Music app
also skips. If so, then there's something funky about your device or
some other app that's running on it. If the Music app is fine, you might
putter around its implementation in the open source code to see if it
gives you any ideas.

Note that your original post got truncated. It ends with "Also, if I".

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://twitter.com/commonsguy

Android Development Wiki: http://wiki.andmob.org

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

On Apr 25, 3:48 pm, henrik <henrik.aron...@gmail.com> wrote:

That looks somewhat similar to the problem I described at:
  http://groups.google.com/group/android-developers/browse_thread/threa...

Seems as if HTC are applying some very aggressive power saving when
the screen is turned off. Unfortunately, I do not yet have a solution
(there must be one [most likely undocumented] as the native phone
application is not affected).

Regards,
Thilo

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

On Apr 25, 9:59 pm, Thilo-Alexander Ginkel <th...@ginkel.com> wrote:

After reading the PowerManager source code, I figured out that there
seems to be an undocumented wake lock for the CPU, which is used along
with a SCREEN_DIM_WAKE_LOCK, but not with a PARTIAL_WAKE_LOCK:

-- 8< --
    private static final int WAKE_BIT_CPU_STRONG = 1;
    private static final int WAKE_BIT_CPU_WEAK = 2;
    [...]

    /**
     * Wake lock that ensures that the CPU is running.  The screen
might
     * not be on.
     */
    public static final int PARTIAL_WAKE_LOCK = WAKE_BIT_CPU_STRONG;
    [...]

    /**
     * Wake lock that ensures that the screen is on (but may be
dimmed);
     * the keyboard backlight will be allowed to go off.
     */
    public static final int SCREEN_DIM_WAKE_LOCK = WAKE_BIT_CPU_WEAK |
WAKE_BIT_SCREEN_DIM;
-- 8< --

Can you try what happens if you acquire the wake lock with the
WAKE_BIT_CPU_WEAK set? I'd try it myself, but am a little short on
time right now.

Regards,
Thilo

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

On Apr 25, 10:23 pm, Thilo-Alexander Ginkel <th...@ginkel.com> wrote:

Well, scrap that idea... Did not try it, but figured out that at
various places in PowerManager.java and PowerManagerService.java
validity checks are put into place explicitly checking for the
documented wake lock masks and counteracting what I proposed with
throwing an (IIRC) IllegalArgumentException or writing an error log
entry. The reason seems to be a valid one, though: The low-level
(native) interface does not seem to care about wake lock masks, but
only knows a couple of dedicated wake locks (PARTIAL_WAKE_LOCK being
one of them). Now, I'd continue to investigate what is going on at the
kernel level, but HTC is refusing to release the source code for the
HTC Desire kernel that I am experiencing the problem with.

Regards,
Thilo

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

@Thilo-Alexander,

I am having the exact same problem as you!  I am developing a download
manager for a particular site and have a service that aquired
PARTIAL_WAKE_LOCK, but when the screen blanks (I press power) the
download pauses.  Downloads make no progress at all when the screen is
off.  If I do a FULL_WAKE_LOCK, I get the expected behavior (screen/
CPU are on full blast).

Did you ever find a solution?

-Jack

On Apr 25, 1:23 pm, Thilo-Alexander Ginkel <th...@ginkel.com> wrote:

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en