This message was deleted.

hmm not too familiar with the bluetooth modes. I’m looking into the bluetooth mic bug you linked, but it sounds like the hfp vs a2dp is a different issue?

The reporter is a team member of me. So its all in the issue reporting. e.g. Android 12

hmm, I think unpublishing would be the way to go, since muting only mutes the input but is still “recording” for android purposes and prevents the switch over to a2dp. will see about making this experience better

In that case, it would be great that it wouldn’t change the audio input device, right? 🙂

@bored-monitor-77074 hey I pushed a fix for the bluetooth microphone issue, can you try version 1.2.2-SNAPSHOT? will need to add

maven { url '<https://s01.oss.sonatype.org/content/repositories/snapshots/>' }

to your repositories to access the snapshot version

Thanks @eager-raincoat-52616, I’ve forwarded it to our Android Lead Dev @late-tiger-55301

@eager-raincoat-52616 Thanks for the update, I've tested in our app using the Snapshot version and sadly it's still same behaviour. Also I pulled the latest main from the repository, trying with the same change in

callViewModel

with sample-app-compose in line

169

localParticipant.setMicrophoneEnabled(false)

Same behaviour. I'm testing with An android 12 device and Android 11 device. The code in the commit

90648076f8d0b490ee3e3789b4482dc3108cf3cd

is executed, i.e. the

audioManager.setCommunicationDevice(audioDeviceInfo)

in the

AudioSwitchHandler

is executed on the Android 12 device, but still same behaviour. It happens with older versions too. Can you let me know in which scenario was the fix working for you? something that can be related, in the

AbstractAudioSwitch

class line 167 there's a comment related to webrtc that on Activating device it says

// Always set mute to false for WebRTC

I'm not sure if that's related? If you would like me to continue discussion on the github issue please let me know.

just as a sanity check, is audioDeviceInfo

info.type == AudioDeviceInfo.TYPE_BLUETOOTH_SCO || info.type == AudioDeviceInfo.TYPE_BLUETOOTH_A2DP

Yes, the info type for the devices I'm testing with is:

AudioDeviceInfo.TYPE_BLUETOOTH_SCO

I mean is that the one that’s being set in the code here? just to be sure

I'm not sure I get you. if you mean in the AudioSwitchHandler> the

when (selectedAudioDevice)

line 87, yes it's that device that is set.

ugh, ok

@eager-raincoat-52616 Do you need to reopen the github issue or do you track somewhere else too?

ah, sorry, will reopen the issue

🙂 Please let us know if you need more feedback/testing etc. Looking forward to this fix. Its pretty crucial for us as you can imagine. Thanks for your support!

will do. @late-tiger-55301 as a mini update, I think I’ve identified the issue to the audio mode; on Android 12 at least (I think may affect android 11 as wel), it seems like MODE_COMMUNICATION just doesn’t support using the bluetooth mic without any corresponding audio output. however, there seems to be an additional issue somewhere compounding this affecting our library specifically

Thanks for the update! Very good find! If you would like me to test some scenario please let me know!

ok, pushed another fix, try the latest snapshot

Okay 👍 testing it.

sorry, which part is the bug on android 11? the music and remote participants aren’t playing at the same time?

I would say that the bug is fixed ( in regards that if there are no other published audio tracks, the current audio input is taken correctly from the bluetooth device even if I'm the only unmuted user ) The problem with music, is that, on connecting to the room, the AudioSwitchHandler calls audioSwitch?.start() and audioSwitch?.activate(). That let's the

AudioDeviceManager

to call

setAudioFocus

. If the user is playing music and then joins a room, the app takes the main focus and the playback is stopped. How we countered this in the app is to call audioSwitch.activate and then audioSwitch.deActivate right after the room is connected. so that the app releases the audio focus and the user can still listen to music. ( that makes the communication mode back to normal, and bluetooth sco is stopped ) and when the user unmutes we set communication mode to IN_COMMUNICATION and start bluetooth sco. It's a bit hacky but it was working, but now it only works for android 12, not for 11. so it's more of a feature request than a bug, the end goal is: User when join a room should be able to continue listening to music and other participant as long as the user is muted. If the user unmutes, then it's okay for the music to be inaudible (due to MODE_IN_COMMUNICATION) and the audio input should still be from bluetooth device.

Gotcha, can you file a separate bug for this?

@eager-raincoat-52616 Thanks will do, I'm just trying to pinpoint the issue. and then will create the bug. thanks a lot for your support 🙌

File an issue, there should be a feature request template

okay thank you 🙏

Sounds good, I can add a flag pretty easily