Back to Top

Prevent headset/lockscreen playback controls from playing Music app's music

13 posts / 0 new
Last post
FunkTrooper
Offline
Last seen: 1 month 1 week ago
Joined: 01/02/2010 - 08:11
Prevent headset/lockscreen playback controls from playing Music app's music

I'm liking that little new feature where DoggCatcher notifies you if some other app steals its audio-playing focus. However, a problem remains...

If I've recently used the Music app to play music, and then I use DoggCatcher, I am unable to use the headset playback controls, or the playback controls on the lockscreen (as included in CyanogenMod). Using these controls will cause music to start playing, and the podcast to stop playing (now complete with a little notification).

But what happens in the reverse situation, where I'm playing some music and had recently been using DoggCatcher? DoggCatcher doesn't start playing instead of the music. The playback controls *only* affect the music app.

Clearly, the music app has some sort of priority over DoggCatcher here. I'm not entirely sure how this works, but would it be possible to 'increase' the priority of DoggCatcher so the music app can't interfere with it. And while nothing's playing, DoggCatcher could just not respond to any playback controls, so it won't interfere with the music app

eric
Offline
Last seen: 1 year 8 months ago
Joined: 11/06/2008 - 22:02
Audio priority

The whole priority thing was removed in 2.2. Now apps grab the primary audio focus and then they become the ones receive the button events. It's up to the app to grab the audio focus responsibly. There are some apps (I've witnessed at least two) that grab the focus when they should not. This yanks the focus away from the app that should have it.

I could put some hostile code in DC to aggressively seek after the focus but that's really not how it should work. Plus, that would cause battles between the apps and the user would lose. What I would suggest, is that if you see an app that is grabbing the focus when it's not either playing or the last one that has played, inform the author so that they can make it play nicely.

When implemented properly the 2.2 focus changes work nicely...much better than the pre 2.2 stuff.

I thought I remember hearing the cm implemented the lock screen by simulating the headset buttons. This is the best way that I can think of a lock screen working because android has all the logic with audio focus to handle the buttons. Piggy-backing on that seems like the right thing to do. It's also possible that the lock screen is directly calling the music player service to start/stop it. If this is the case, then we're out of luck.

JNavas
Offline
Last seen: 9 years 5 months ago
Joined: 11/08/2010 - 10:59
Playing nicely together

Putting a "hostile" audio focus mode in DC to deal with badly behaved apps would make DC no better than they are and would inevitably be bad for users. I address such problems by removing badly behaved apps (like Listen) from my mobile, and would hate to lose DC as a result.
My $0.02,
John

FunkTrooper
Offline
Last seen: 1 month 1 week ago
Joined: 01/02/2010 - 08:11
The lock screen can't be

The lock screen can't be directly calling the music player service, as it works perfectly with DoggCatcher as long as the Music app has not been running recently. The behaviour of these buttons is identical to those of the headset controls, so I can only assume that it's 'emulating' those.

I assume the music app maintains its hold over the headset/lockscreen controls so that you can unpause music that you've recently paused. This makes a lot of sense, as if you were *only* using the music app to listen to stuff, it would probably be a desired feature -- you wouldn't want to be able to pause, but not unpause a song.

Perhaps the aggressive focus-seeking could be an off-by-default optional feature...

JimInWoodstock
Offline
Last seen: 10 years 6 months ago
Joined: 09/22/2010 - 17:40
My situation with DC audio focus

Here is my situation
The phone is the Motorola Droid X with 2.2
The application that takes the audio focus from DC is the built-in "Music" app.
I love DoggCatcher, but I am not using it because of the "lost audio focus" problem.
I am listening to podcasts at least a couple of hours a day and not being able to use my headset pause button is a show stopper for me.
If I use DoggCatcher to listen to podcasts, when I want to pause for whatever reason, I have to remove the phone from my belt holdster, slide my finger over the screen, go to the home screen if Doggcatcher is not on the screen and launch DoggCatcher, and then touch the pause control on the screen.

I bought the Doubletwist application some time before I discovered DC. The thing is, it works perfectly with the pause button on the headset.
Here is the way things work on my phone.

Set DC "bind to headset" on.
Start DC play for a podcast and then click the pause button on the headset. The podcast pauses and then resumes playing when clicked again. The will work every time until I allow the phone to go to sleep either with the audio playing or paused. As soon as I click the pause button on the headset, the Music app will respond and start playing whatever it was playing last. This will continue until I restart DC. Then it will respond again to the button until the phone goes to sleep.

Now, set DC "bind to headset" off.
Set "headset controls" setting to "on" in Doubletwist
Start playing a podcast. Doubletwist now responds to the headset button and continues to do do from now on. It never loses the audio focus.
I don't especially like DoubleTwist but it is so much easier to just reach up and click the pause/play button on the headset instead of doing all the steps described above.

It seems to me that if DoubleTwist can work perfectly with the headset button, then DC should be able to do so also. I, of course, have no idea how the code in DoubleTwist works. I just know that whatever they are doing, it is pretty much bulletproof when it has the audio focus.

Please look into this and see if DC can be updated to do the same thing. I really miss DC and all it can do, but the audio focus problem kills it for me.

FunkTrooper
Offline
Last seen: 1 month 1 week ago
Joined: 01/02/2010 - 08:11
This may be different on the

This may be different on the inevitably-customsised Motorola music app, but in my experience, if you completely quit the music app, then it won't interfere with DoggCatcher. This may require you to use a dreaded task killer just to get rid of the music app. But once the app is completely quit, it won't start playing music in the middle of a podcast again.

I know this isn't really a proper solution. But it's better than nothing, I guess.

eric
Offline
Last seen: 1 year 8 months ago
Joined: 11/06/2008 - 22:02
DoubleTwist

First let me say that this is a painful subject for a lot of people. The android apis have changed over time and different devices have some different behaviors that make this pretty complicated to get working peacefully with multiple apps.

I checked this out and I'm not going to be able to do what it's doing. Not for technical reasons, but because the api for binding to headset buttons changed starting with 2.2 and there's a prescribed approach for apps to share the buttons. Shortly after 2.2 was released I migrated DC to use this new api.

From what I can tell, and I may be wrong, but it looks like in DT, whenever the preference is enabled to bind to the buttons, the app responds to them, regardless of what other apps are doing. So maybe the app
hasn't been upgraded to support the newer apis.

So with that preference enabled, there isn't a way for more than one app to respond to headset buttons without changing preferences in applications. I also noticed that it's not grabbing the primary audio focus so you can end up with multiple audio streams playing on top of each other. If someone from DoubleTwist reads this and I'm wrong, please correct me...I'm just guessing from watching console output.

I'm trying pretty hard to stay withing the recommended uses of the api because as soon as DC steps outside of that, another app will need to do the same to compete with it for buttons and then it'll be the same chaos we had before 2.2.

Here's a faq article that goes into how things should work - http://www.doggcatcher.com/node/858

I think one thing that may be making this worse for you is that DC is losing the audio focus when the devices goes to sleep. That shouldn't be happening. According I had an early rom for my nexus one that had the same problem but it was fixed in a subsequent release. In my case, the music app was grabbing the audio focus in certain circumstances. This sounds like the same thing is happening to you. I think I remember another 2.2 droid user reporting the same thing.

JimInWoodstock
Offline
Last seen: 10 years 6 months ago
Joined: 09/22/2010 - 17:40
How about this

Eric,

I have an idea.
First of all I agree with your decision to keep DC within the guidelines of v2.2.
You already have the code to detect losing audio focus in the current version. How about a setting that says something like "keep audio focus at all times" or something like that. This setting would make DC grab audio focus when it detects that it just lost audio focus. Set this setting to "off" in the default settings so that the phone is staying under the v2.2 rules. For those that want it(me! and many others apparently), they can set this to "on". Their phone would now work just with DC as the only app that can use the headset button. If they want to go back to the standard setting honoring the standard android audio behavior, the can just change the setting to "off". For me, this is the setting that I want. I think that a lot other people would want this also.
If you agree and this is a pretty easy change (I am doing wishful thinking here about the effort to do this since the code to detect losing audio focus is already in DC), please think about placing this on your soonest to do list. I sure would like to start using the DC app again for my podcasts.

eric
Offline
Last seen: 1 year 8 months ago
Joined: 11/06/2008 - 22:02
Interesting idea

That's interesting and might work but I'm not sure yet because there are two things in play here. First there's the audio focus which is what DC can respond to, and then there's receiving buttons events. I'm not positive it would work reliably but I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=723

I would be scared to see what would happen if another app decided to do the same thing...it could likely make your phone explode.

JimInWoodstock
Offline
Last seen: 10 years 6 months ago
Joined: 09/22/2010 - 17:40
John, Keep in mind that this

John,

Keep in mind that this suggested function only would be "on" if the user wanted it. If it was causing bad things for podcast playing, the user could just set it to "off" and everything would be back to normal.

BTW, how are you removing the listen app from your phone? The listen app is in the rom on my droid x and it is my understanding that the only way to get rid of it is to root the phone. Is there another way? I would love to get rid of that app.

JNavas
Offline
Last seen: 9 years 5 months ago
Joined: 11/08/2010 - 10:59
Law of Unintended Consequences

Hi Jim,

I missed your reply to me until now because it wasn't posted as a Reply to my comment -- sorry. My responses:

1. The Law of Unintended Consequences tends to bite when rules are broken to work-around issues. For example, a newbie might turn the option on inadvertently, and then get really upset when the handset goes haywire. Even techies may not realize the option is causing problems. So I don't think it's a good idea in general, and if done, needs to be buried in an Advanced sub-menu with plenty of warnings, with a simple global action to restore normal behavior (defaults).

2. Google Listen is not in the stock Android load for my Nexus One (currently FRG83D) -- I install and uninstall it in Market. Having stock Android (without modifications by handset manufacturer or carrier) is part of why I have the Nexus One.

John

JimInWoodstock
Offline
Last seen: 10 years 6 months ago
Joined: 09/22/2010 - 17:40
Final post in this thread

I am now putting down my drum that I was beating for changing DC in reference to the headset controls. I have recently rooted my phone and installed Titanium Backup. This program will "freeze" any application. I froze the music app and now DC works perfectly with the headset controls. It is really nice to be able to use DC again for my podcasts!

eric
Offline
Last seen: 1 year 8 months ago
Joined: 11/06/2008 - 22:02
Cool idea

Glad you got it working and you're back on DC.