mcuradio and mediaplayer counter detect each other

[hvdwolf]

To continue the conversation here of the radio-musicplayer mixing instead of in the topic:

In gustdens launcher script we use the input keyevent 127 when the radio goes to sleep. This is a command to pause the active media player (of course in SofiaServer "language") Can the mcuradio issue such a command on startup thereby pausing the active mediaplayer?

And vice-versa in the MCUd or the BD37033Controller: If it detects music being played by any "normal" android app via AudioManager.isMusicActive();, it could blindly issue a command like am force-stop tk.rabidbeaver.mcuradio or a nice java equivalent via ActivityManager. (I guess it should be mcud because of the necessary system authorizations to stop another app and it constantly being running in daemon mode)

(There is some documentation in https://developer.android.com/reference/android/media/MediaPlayer.html and other topics.)

Do you think this could be successful? I know it is not the nicest way to achieve this and actually a likewise shoestring construction as Joying uses, but at least it is a good end-user solution.

Edit: Of course it should be a temporary solution until the Android 8 option does it correctly.

[lbdroid]

I'm sure your question makes sense to you, but it doesn't make any sense at all to me. Why would you want the radio to pause the "active media player"? How do you define the "active media player"?

[hvdwolf]

When a mediaplayer is running on Android, be it poweramp, rocketplayer, pandora, spotify or whatever player, and it is outputting music, it can be detected via the AudioManager.isMusicActive(); So when the radio app is started it should check for AudioManager.isMusicActive();. If the radio app detects "true" for that event, which relates to any media player playing music (what I call the "active media player"), the radio app should simply send the pause command, which will pause the currently playing media player through the audio HAL. This could be done via a likewise command of the input keyevent 127. You don't need to know which media player is playing. Android will pause the "active media player" using the audio HAL where the android apps register themselves.

As the mcuradio is playing via the bd37033controller, it is currently not using the audio HAL. Therefore, the mcud should also listen to this same AudioManager.isMusicActive();. If mcud detects a change from "false" to "true", so when a music player starts outputting music, the mcud should issue an am force-stop tk.rabidbeaver.mcuradio. Or more elegant: When mcud detects a change from false to true for AudioManager.isMusicActive();, it should check if the radio is running and if it is running, mcud should stop the radio app.

So even on the joying units with the audio HAL and the BD37033Controller currently separated/disconnected, this would mimic the behavior of an android phone where it is all going through the same audio HAL where android is doing that automatically: if a new music app starts , the other is paused/stopped.

[lbdroid]

1) MCUd is a native executable. It can't run java functions. 2) Even if it could, that would break all kinds of transient sounds (like the jerking software DOES -- play a sound, audio source changes to android, does not change back). 3) The AMFM radio does not HAVE an on/off mode. It is always on. 4) I believe that you think that the radio application actually does something. It doesn't. You press a button, it gets forwarded as a preset instruction to the mcu. There is nothing "running". If you kill it, that will not affect the state of the AMFM radio. 5) I definitely do NOT want to have software trying to guess if that sound that just started playing is a music track or a notification like a navigation instruction (which is not the same as a general notification sound).

What you are asking is NOT POSSIBLE without implementing proper audio and radio HALs.

[hvdwolf]

1. OK. I did not think of that.
2. (and 5.) That's why I mentioned "the same shoestring construction Joying uses". You have to register the navi app in the Joying carsettings software. Then SofiaServer knows that when the radio is playing, and the navi app outputs an instruction, it should only suppress the radio audio temporarily. So that in that case it DOES change back from android to radio. And the mcuradio pausing "any" media player during startup is still valid, even if at that moment a navi-instruction is played, as that is simply a temporary 10-30 seconds "media player" action.
3. see 4.
4. My error. I knew it was a 2-layer construction where also the joying radio is only a gui forwarding commands to the underlying hardware and getting info from it, but I did not know that the radio was actually always on. It thought the underlying (software) layer switched off the hardware.

5. That combines with 2: the registration of the navi app in the joying car settings. This could still be a text file with all navi-apps somewhere in /etc. Just like it is now in the assets of the SofiaServer. If a new navi-app comes to the scene it could be easily added (but Gustden and I already collected a big list).

   I don't have your programming skills, and neither your programming experience. I understand your (absolute?) requirement for a clean implementation after the horrible band-aid solution Joying gives us and I know you don't want us nagging for options that break that clean implementation. But I prefer a 98% clean implementation with 2% temporary, perhaps awkward work-arounds, to achieve a higher user-friendliness and smoother end-user experience. I look at it from user perspective. I know it can't be "properly" implemented on this 6.0.1 version, that's why I call it band-aid solutions.

And once on Android 8 all those work-arounds and band-aid solutions will be removed using the mentioned proper audio and radio HALs.

[lbdroid]

I'm not entirely sold on there actually being any need for automatically switching the inputs. And I am ABSOLUTELY against trying to implement the broken shit that jerking made. That was absolutely insufferable and unacceptable.

But I do have a solution for you. However, there is a catch; you will need to do most of it yourself, because I have bigger fish to fry.

Find where the Android system calls the onResume() method of activities. Write an xposed module to hook that system method, and in the hook's beforeHookedMethod method, compare the activity being resumed to a list (that you define elsewhere). If your list has a match, then send a broadcast to the BD37033Controller that instructs it to switch the input.

That's the first part, which will be able to switch the primary input to something appropriate for the application you've just started, but there is one hole in what we have so far -- while it can switch to the AMFM radio when you start the radio application, it will NOT be able to stop the sound from the media player from mixing with the radio. We need to keep the mixer ON in order to receive navigation instructions and system sounds. So you will have to do one ADDITIONAL action in that hook, which is IF the requested primary input is NOT Android, KILL or PAUSE ALL THE MEDIA PLAYERS... which you will already have defined in your list, so its no big deal to guess which ones to kill. Or perhaps if you are lucky and all the media players you're interested in will respond favorably to a PAUSE KEY EVENT, then that could also work.

I'll upload an example simple xposed module that you can use as a pattern.

[lbdroid]

Here is an example module; https://github.com/lbdroid/ExampleXposedModule

After a meeting I have to be in, I'll describe it a bit.

I added a readme to the project that explains it.

[hvdwolf]

I will examine it this weekend (possibly starting tonight)