I have a for loop as part of a background thread in my code. Part way through execution of the code within the loop I want a wait period so I call thread.sleep. I've discovered that if the phone display closes during the wait period the wait time becomes erratic. According to the documentation sleep is not time reliable. So I am wondering what to substitute. As far as I can see if I create a post delayed sub thread I will loose the continuity within the for loop. I hope I am wrong and have'nt understood the mechanics properly - any help appreciated.
Ron
One way to deal with the unreliability of sleep() is to add code to measure the actual time you slept. This is often done in animations where a decision can be made to, for instance, skip some number of frames to catch up to real time.
Can you just use Handler and call postDelayed? I honestly can't claim how reliable that will be or if it fits your problem but I use it for small regular updates.
You might also look into Partial Wake Locks to see if that might give you more reliable performance.
You need something like this:
(...)
Message msg = new Message();
try {
myHandler.sendMessageDelayed(msg,1000);
} catch (Exception e) {
Log.d(TAG,"Hum?",e);
}
}
}
private Handler myHandler= new Handler() {
/*
* (non-Javadoc)
*
* #see android.os.Handler#handleMessage(android.os.Message)
*/
#Override
public void handleMessage(Message msg) {
//DO WHAT YOU WANT..
}
};
Related
Hey I am currently designing an app where some code gets executed every 200ms. The thread I use for this looks like this (simplified):
final Handler handler = new Handler();
Runnable runnable = new Runnable()
{ public void run()
{
handler.postDelayed(this, 200);
switch (status){
case 1: check(1);p2.setBackgroundColor(0x00000000); p1.setBackgroundColor(0xDDCC0000); status = 2; break;
case 2: check(2);p1.setBackgroundColor(0x00000000); p2.setBackgroundColor(0xAAAA0000); status = 1; break;
}
}
}; runnable.run();
check() contains some non-UI code lines.
The problem is, that the postDelayed-200-ms start, when the queue is fully executed and not at the beginning so all time that the system needs to execute the commands stacks and stacks all the time so these are actually ~210-230ms (depending on CPU load)
Then I tried to get the system date at the beginning of the thread and add 200ms to it but this results in some other, "heavier" errors.
I have no problem with more than 200ms delay, I just want to get it running stable.
I hope you understand my problem and can give some advice to me.
EDIT: I know got to know that the Handler runs acceptable (delay of 4ms on 200ms). The problem are the methods I am calling then. I will open a new question
If check() contains non-ui code lines then you should run those in a separate thread.
The bottom line is that the UI thread is *really busy, so, you can ask it to do something every 200ms but you aren't guaranteed any precision since the Device is doing its best to do all sorts of other things. When you say "heavier problems" what do you mean exactly?
I would try to start a Thread and just Log every 200ms to see if the device is willing to accurately do *anything at the rate you wish. If it does, then you can send messages to the UI thread to draw and if you find that its the drawing that is delayed, then perhaps you need to reduce your delay to give the UI thread time to finish drawing? (obviously this is also highly imprecise and will vary wildly from device to device).
Did you try doing it using Timers? A basic implementation would look like
new Timer().scheduleAtFixedRate(new TimerTask() {
#Override
public void run() {
// TODO Auto-generated method stub
}
}, 200, 200);
You can try using the alarm service as well. that should give you accurate (or at least consistent) results.
Apparently no exception is thrown so that I can recognize an error while buffering streaming audio content. For example I've disconnected my router and the app will continue to try to buffer the whole time. When I reconnect then it completes buffering and continues even after being disconnected for over a minute!
So the problem is I can't let my user sit there for that long without considering that a problem. What is the proper method to detect a buffering problem with the Android media player?
I'm thinking about using a Timer for a timeout. I'll start probably with 15 seconds (using a proxy I tested a 5kbps connection, which would be a worst case, was able to start playing in 6-10 seconds, so I think 15 seconds would be a reasonable timeout period). Does this sound like a good plan? If so should I create a new Timer with each buffer attempt or should I keep the same Timer throughout the lifetime of the playback service?
So basically I'm asking two questions:
1) What's the proper way to detect if a buffer is having a problem? Is there a listener I'm overlooking? I've tried MediaPlayer.OnErrorListener of course that doesn't fire in my tests. My conclusion is I have to have a timeout to detect a buffering error.
2) If I'm correct on number one, what is the proper way to use a Timer? Create one with each buffer attempt or reuse the same one? EDIT Also should I restart the (or cancel and create a new) Timer onBufferUpdate? With the onBufferUpdate listener I should know that some data is coming back so should maybe reset the timer with that.
From your question, I understand that the primary objective is to detect a situation if your player is stalled due to buffering and take some actions thereof. To handle this situation, I feel that the following 2 listeners may be helpful to identify the same.
MediaPlayer.onBufferingUpdate would provide the timely progress of the buffering. So, if there are 2 callbacks with same percent value, this could be an indication of potential buffering.
There is another listener MediaPlayer.onInfoListener which has some specific events which could be of interest to you. On this listener, if the what is MEDIA_INFO_BUFFERING_START, this would indicate that the player is pausing the playback for buffering i.e. trigger for your logic. Similarly MEDIA_INFO_BUFFERING_END indicates the restart of the playback after filling the buffers.
You Should see this article. The mediaplayer has a ErrorListener to get any error.
http://developer.android.com/reference/android/media/MediaPlayer.OnErrorListener.html
int count=40;//for 40 seconds to wait for buffering after it will finish the activity
//boolean timeoutflag=false;
timeout = new Handler(Looper.getMainLooper()) {
#Override
public void handleMessage(Message msg) {
System.out.println("value of count="+msg.getData().getLong("count"));
if (msg.getData().getBoolean("valid")) {
if (msg.getData().getLong("count") == 0 && !timeoutflag)
{
if (pDialog != null && pDialog.isShowing())
{
try
{
pDialog.dismiss();
}catch(Exception e)
{
e.printStackTrace();
}
}
Toast.makeText(getApplicationContext(),
"Unable To Load This Video", Toast.LENGTH_LONG).show();
finish();
} else {
}
}
}
};
timeout.postDelayed(null, 0);
new Thread(new Runnable() {
#Override
public void run() {
while (count > 0) {
try {
Thread.sleep(1020);
} catch (Exception e) {
}
Message msg = new Message();
Bundle b = new Bundle();
b.putBoolean("valid", true);
b.putLong("count", --count);
msg.setData(b);
timeout.sendMessage(msg);
}
}
}).start();
// set timeoutflag=true; in setOnPreparedListener of video view
For buffering during preparation, you have to set your own timer which calls player.reset() after some interval. This puts the player back into init state.
For buffering after preparation (during play) you have to monitor getPosition(). If it falls behind some maximum, call reset(). This allows you to set an experience threshold for your playback. Handles not only failed connection, but also choppy connection.
Best solution is to not use MediaPlayer. Use a public VLC derivative instead. MP has too many internalized private design limitations requiring horrible workarounds (eg. CANT add codecs). RTFM gives you false hope in this case.
Unless you are doing a very straight laced android app, don't depend on any android api. Some opensource substitutes are better supported, and for good reason.
(really bandeely olly jolly satisfying editorial rant deleted)
I'm facing a problem where I want to play a half second long AudioTrack in static mode repeatedly, but the sound is choppy. However, I noticed that the sound is perfectly clear while a TransitionDrawable is running in parallel.
A simplified skeleton of my code is:
thread = new Thread(new Runnable() {
public void run() {
createTransition();
try {
createAudioTrack();
while (true) {
if (audio) {
playSoundClip();
}
if (display) {
playScreenTransition();
}
Thread.sleep(getDelayBetweenBeats());
}
} catch (InterruptedException e) {
} finally {
resetScreenTransition();
stopSoundClip();
}
}
private void createAudioTrack() {
short[] samples = generateSamples();
track = new AudioTrack(AudioManager.STREAM_MUSIC, SAMPLERATE, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, samples.length * 2, AudioTrack.MODE_STATIC);
if (track.getState() != AudioTrack.STATE_UNINITIALIZED) {
track.write(samples, 0, samples.length);
}
}
private void playSoundClip() {
if (track != null && track.getState() != AudioTrack.STATE_UNINITIALIZED) {
track.stop();
track.reloadStaticData();
track.play();
}
}
private void playScreenTransition() {
view.post(new Runnable() {
public void run() {
view.setBackgroundDrawable(transition);
transition.startTransition(DURATION);
}
});
}
});
thread.start();
As you can see thread is not performed on the UI-thread so I assume that the track is facing multithreading problems. I don't think that the UI-thread that plays the transition consumes the entire CPU since my audio is playing in parallel. It seems as if the activity somehow consumes the CPU and nothing else is executed.
I had tried to use view.post(new Runnable() {...}); in playSoundClip(), too, but that didn't help.
I thought about changing all into an AsyncTask, but IMHO that wouldn't change anything as it would still be a background task. Since I don't need to update an UI-element with the sound and the transition still has to play in parallel I didn't even try that.
A solution would probably be to always have some transition running in parallel (the actual one or a dummy one), but that just sounds bad (pun?) to me.
Does anyone know of another way how I can make track play clear at all times?
EDIT:
After working some more in this issue and extending my program I noticed that I have to use a threaded approach like I lined out above as the logic in there takes some time to complete and I can't do it all on the UI-thread any more. Currently I play a dummy transition while the audio is playing, which still sounds bad to me. Therefore, if you can still contribute some insights into this topic you are welcome to post/answer them here.
You might want to take a look at SoundPool, which would allow you to statically load your short audio sample into memory once and then play it on-demand with much lower latency. The way in which you are using AudioTrack is a good use of replaying the audio without reloading, but it might still be a bit heavy-weight for such a short and often repeated sound byte.
You might also consider not using a background thread at all. It looks from your snippet like you are really just using the Thread as a timer, and you might get better performance out of using a Handler to post your Runnable on a timed interval (which would also allow you to call your audio/transition methods on the main thread) instead.
HTH
I have much larger chunks of audio but I have had luck playing them in a Service that I created.
P.S. Nice Pun
I have a problem with this code used for Android (Java)
handler.postDelayed(new Runnable(){
public void run(){
// Your code goes here...
}
}, 500);
If the delay is about 500ms then the program seems to repeat the task at 0.5s, but if I change to less than 100ms or even less it does not follow any more. I test the brightness change and for a while it can repeat the change of brightness at that rate, but then slow down and come back to normal flash rate again. It seems unstable. Do you have any code that give exact delay regardless of the load of the phone's CPU.
Many thanks
Not from Java, no; stock Java isn't a real-time system.
Timing precision is subject to the whims of the JVM and the OS's scheduler. You may be able to get incrementally more precise, but there's no guarantee of the kind of precision you're looking for.
You might be able to do something more precise if you use a CountDownTimer which has a periodic tick. Essentially you set it to count down for a period which can be hours if need be, and there are two methods one method is called on each tick, and the other at the end of the timer at which point you could start another one. Anyway you could set the tick to be very fast, and then only kick off the code at the delay point by check the actual time difference in the click. I think thats about the best you could do. Essentially inside the tick you would issue a signal if the right amout of time had actually passed. That signal would either kick off the thread or release something the already running thread was waiting on. What is the value of the CountDownTimer, I guess its just that you can do a very frequent polling, and elapsed time check. Although its not guaranteed, the time between the ticks you can set it to a high frequency and check/poll very frequently. This could lead to a smooth performance not unlike a realtime system. Its more likely to be accurate because its just issuing a signal and not taking up the resources of threading just to issue the signal. You might also try an IntentService to perform the tasks and just call startService(intentToIntentService) each call. See if the threading works better inside a service like IntentService which does queue them up I believe.
Date startDate = new Date();
long startTime = startDate.getTime();
// Tick called every 10th of a second. OnFinish called at Signal.
CountDownTimer ctDownTimer = new CountDownTimer(30000, 100) {
long startIntervalTime=startTime;
public void onTick(long millisUntilFinished) {
Date now = new Date();
long nowTime = now.getTime();
if ((startIntervalTime - nowTime) > 100)
{
issueSignal();
intervalStartTime=nowTime;
}
now=null;
}
public void onFinish() {
Log.d("MyClass", "Done") // Maybe start out.
}
}.start();
I have an app that plays an mp3 file and I'm trying to update a custom field in synchrony with certain times we have tabulated for the sound playback (kind of like a karaoke effect). I'm using a Handler to schedule these updates. In my custom field class, I define a Runnable that is supposed to run the update at the right time:
private final Runnable mTrigger = new Runnable() {
#Override
public void run() {
int now = mPlayer.getCurrentPosition();
if (mState == STATE_PLAYING && mUpdateAction != null) {
if (mTriggerTime - now > MAX_PREMATURE_TRIGGER) {
// Sound is lagging too much; reschedule this trigger
mHandler.postDelayed(this, mTriggerTime - now);
} else {
// Run the update
mUpdateAction.run();
}
}
}
};
When I call mPlayer.start() I schedule the first update by calling mHandler.postDelayed(mTrigger, timeToFirstUpdate). Each update action decides what the next update will be and schedules it (by calling mHandler.postDelayed(mTrigger, timeToNextUpdate)). The updates times are typically a few hundred milliseconds apart.
The problem is that, while some updates are happening promptly at the scheduled times, others can be delayed by 200 milliseconds or more, which is quite noticeable to the user. I'm not doing anything in my app between these updates other than playing the sound. (No background worker threads; no other display updates.) The delays appear to be random and vary considerably each time through.
I didn't think that the timing for postDelayed would be this imprecise! I don't know if this is an emulator issue or a problem with my approach. Does sound playback screw up the timing of the UI thread loop? Should I move the timing into a background thread (and is it safe to call mPlayer.getCurrentPosition() from a background thread)? Something else?
After much experimenting, it seems like the problem is the emulator. When I ran everything on a speedier workstation, the problem seems to have gone away.