Correctly Handle Transient Audio Focus Requests

[Trevelopment]

Just some small changes, AA doesn't need to capture transient requests to hear navigation also this messes up audio focus when dealing with BTFH. This solves those things and you can see at how here #105
Also, dont set FocusType::NONE on temporarilyLost focus event to allow AA music player to resume playing when the transient stream passes audio focus back or else the music pauses.

fixes #105

[lmagder]

Does navigation still play over non-AA audio? I think AA still needs to take temporary focus to do this. There is no magic with nav, we are actually mixing it ourselves in the app :)

[Trevelopment]

I still need to test with Google Maps but so far with Waze I have found that navigation audio does still play even if AA does not have audio focus. And it acts like any other transient stream I don't know how it works out like that but its been working for me. The only thing that doesn't automatically take audio focus is the mic and it's only the audio output you don't hear if AA does not have audio focus, input through the microphone works fine either way.

[Trevelopment]

@lmagder II don't know if you've tried this build yet but can confirm that at this commit all the audio focus transitions work correctly with GMaps, Waze, Phone Calls, MZD and AA Audio Players the only exception is in the case of the output audio when using the voice command button if AA does not have audio focus. Microphone still works fine regardless so It still works if you are listening to the USB audio or XM and say like "navigate to work" and if you have the nav sounds on then the navigation will take transient focus and you will hear the end of the voice response too.
So I was trying to rack my brain about why I never saw the navigation taking focus in the logs and how it still worked after this commit. so I just told it to navigate me to work and drove around the block several times so that she would just constantly be yelling at me and looking at the log I noticed something.

KEY_T (any audio focus: 1 media focus: 1)
audioMgrReleaseAudioFocus()
requestAudioFocus({"sessionId":16})
{}
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"MLENT","streamModeName":"MLENT","newFocus":"lost","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 23 for stream MLENT
AudioFocusHappend(0)
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"USB","streamModeName":"USB","newFocus":"gained","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 16 for stream USB
W: /home/mazda/headunit/hu/hu_aap.cpp:622: hu_handle_AudioFocusRequest : AudioFocusRequest Focus Request AA_CH_CTR: 3
audioMgrRequestAudioFocus(1)
requestAudioFocus({"sessionId":23})
{}
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"USB","streamModeName":"USB","newFocus":"lost","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 16 for stream USB
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"MLENT","streamModeName":"MLENT","newFocus":"gained","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 23 for stream MLENT
AudioFocusHappend(1)
W: /home/mazda/headunit/hu/hu_aap.cpp:622: hu_handle_AudioFocusRequest : AudioFocusRequest Focus Request AA_CH_CTR: 4
audioMgrReleaseAudioFocus()
requestAudioFocus({"sessionId":16})
{}
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"MLENT","streamModeName":"MLENT","newFocus":"lost","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 23 for stream MLENT
AudioFocusHappend(0)
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"USB","streamModeName":"USB","newFocus":"gained","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 16 for stream USB
W: /home/mazda/headunit/hu/hu_aap.cpp:622: hu_handle_AudioFocusRequest : AudioFocusRequest Focus Request AA_CH_CTR: 3
audioMgrRequestAudioFocus(1)
requestAudioFocus({"sessionId":23})
{}
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"USB","streamModeName":"USB","newFocus":"lost","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 16 for stream USB
AudioManagerClient::Notify signalName=audioFocusChangeEvent payload={"streamName":"MLENT","streamModeName":"MLENT","newFocus":"gained","destination":"Cabin","focusType":"permanent","streamType":"Media"}
Found audio sessionId 23 for stream MLENT
AudioFocusHappend(1)
W: /home/mazda/headunit/hu/hu_aap.cpp:622: hu_handle_AudioFocusRequest : AudioFocusRequest Focus Request AA_CH_CTR: 4
audioMgrReleaseAudioFocus()
requestAudioFocus({"sessionId":16})
{}

I think you know what that means AUDIO_FOCUS_UNKNOWN should be AUDIO_FOCUS_NAVI
So I also tried putting AA_CH_AU1 onto informationNavi and informationGeneric and the good news is that they did take transient focus on the voice command button when AA didn't have focus but didn't play any sound, it would just go blank for a second. Mic still worked fine. So I was thinking there is another channel AA_CH_AU2 that looks like we may not use it, what is up with that? is that what the Navigation is set up on?
I am also going to try some things to use the transient focus but store what had focus before BTHF so it can just request focus after. That would pretty much solve that last transition because then we could capture the transient requests just fine.

[lmagder]

@Trevelopment I havent had a chance to mess with it much. I was trying to debug the GPS accuracy stuff and I think found a fix, but other than that haven't had much time.

Argh that's annoying it, feels like you are so close. When you were playing to informationNavi did you also call requestAudioFocus with a channel which maps to that stream? Maybe that's why it's playing nothing? If the code was switching to MLENT still the CMU mixer was using the other ALSA device maybe and you got silence?

Nice! we know AUDIO_FOCUS_UNKNOWN is finally. It's possible the AA doesn't actually do "transient" focus the enum actually could be like Media, Nav, and Voice Prompts for all we know. I have no idea about AA_CH_AU2 honestly. I know when we enabled it all the non-media sound started coming from the phone speaker (I know, that makes no sense since we are adding more audio to the car) so I was just like "Hmmmm, no" and turned it off and didn't investigate further.

[Trevelopment]

Well hey @lmagder I got it buddy.

Its seems like the answer is so obvious once you figure it out its always just one tiny detail that you have to consider or path through the code to follow to find the spot where you need to handle the problem. So we handle the audio focus request in MediaStart() and ignore the request from AudioFocusRequest() and it works like a charm. Perfect transitions between transient streams, phone calls, music mic they all work correctly, no need to use a new alsa device although that did kind of work in the end too (on "default" channel... didn't sound great).

[lmagder]

Awesome! I'm going to give this version a try. Keying on the mic is a good idea. I didn't think of that. 👍 I want to make sure other stuff like reading a text when clicking on the notification still works though since there is no mic involved (possibly it activates the mic anyway incase you respond so maybe it's fine?)

If not, it looks like there is a way of querying if a call is active via the com.jci.bthf DBus interface so maybe we can only ignore the AudioFocusRequest() if there is a call pending? Hopefully that state changes in CMU early enough. Maybe this is unnecessary though, need to test.

Also you still probably want to pass and track AudioManagerClient::FocusType::TRANSIENT for the NAVI focus. It actually doesn't do anything other than control if the Next/Prev track buttons are passed on or consumed based on what is set in currentFocus, it has nothing to do with the CMU audio stuff really. You would need to hit next track at the exact moment a navigation prompt is playing to notice the difference but I guess people could do it even if it's rare.

[Trevelopment]

Yea I saw a few places the code could be cleaned up a little bit too but I will leave that for you 😁. As it is now I tested every type of audio focus transition I could think of and they all worked fine but you're right I missed the incoming text notification. Are there any other times AA needs/takes audio focus that i should consider?

[Trevelopment]

@lmagder I messed with querying the BTHF state back when I was looking at the first bluetooth call bug and on #16 I discuss it a little bit with @borconi.
The signals from the MZD are

message CallStatus
{
  enum BTHF_STATE
  {
    BTHF_STATE_IDLE = 0;
    BTHF_STATE_INCOMING = 1;
    BTHF_STATE_ACTIVE = 2;
    BTHF_STATE_END = 3;
  }
  required BTHF_STATE bthf_state = 1
}

I got those values from testing with testapp_btfh on the CMU
but I think the headunit values are

Phone_Status
{
enum Call status {
   - Inactive
   - in call
   - incoming
   - on hold
   - muted
   - conferenced
}
- Duration (int32)
- Thumbnail (bytearray)
- caller number
- caller id
}

I think watching for BTHF_STATE_INCOMING and BTHF_STATE_ACTIVE from the BTHF CallStatus signal handler will probably do the trick.

[Trevelopment]

OK so one thing I found because I've been spamming the mic like crazy but the very first time you press the mic button you usually don't hear the first "beep" that kind of prompts you to say something, you know what I mean? but by the time you say the command it will have taken focus and you will hear the response so it's not too big of a deal just a nit. Other than that it seems like it's all working pretty smoothly with a tiny bit of clean up it could work perfect.