Zoom android sdk on Oculus Quest - Cannot change call volume

Meeting SDK Android
1

Description
I’m trying to add webrtc audio capabilities to my Oculus Quest application.
I tested both the zoom official APK from playstore and the sample app included in the SDK on Oculus Quest.
Unfortunately I have not been able to change volume of the call with the hardware buttons.
The volume UI comes out, and it looks like the volume goes down (or up) but the actual one stays unchanged.
This behavior might be related to the fact that Oculus Quest redirects any type of audio into the STREAM_MUSIC, even if AudioManager’s mode is MODE_IN_COMMUNICATION and the AudioTrack responsible for the audio stream is directed towards the STREAM_VOICE_CALL.

To be noted is that if I try to launch a direct call to another zoom user, the caller (and only he, not the callee as well) can actually change volume successfully.
If there is any noteworthy difference in terms of meeting configuration that I could apply also to normal meetings, It would be nice to know.
I couldn’t find any info about how to start a direct call anywhere, and I’m not able to decompile the official apk in order to see how it is done.
A link to a guide in this regard would be already much appreciated.

Is it possible maybe to redirect the call audio towards STREAM_MUSIC (which is controllable from Quest) ? This could work too.

Any help or insight in this matter would be truly appreciated.
Thanks
Massimo

Which Android Meeting SDK version?
zoom-sdk-android-5.7.1.1268

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. compile sample app (found inside sdk) into apk and run onto Oculus Quest
  2. join/create a meeting
  3. try changing volume while the other participants talk
  4. See that while UI changes, the actual volume does not

Smartphone (please complete the following information):

  • Device: Oculus Quest 2
  • OS: Android 10
2

Hi @massimo.bortolamei, thanks for using our SDK.

In the spirit of transparency, since this behavior is reproducible on the Zoom client, this may be something that needs to go through our Help Center. I’ll see if there’s anything we can do on the SDK side to address this.

This behavior might be related to the fact that Oculus Quest redirects any type of audio into the STREAM_MUSIC, even if AudioManager’s mode is MODE_IN_COMMUNICATION and the AudioTrack responsible for the audio stream is directed towards the STREAM_VOICE_CALL.

This is interesting and good to know. Based on this, it would seem that there may actually be a method through which it is possible to circumvent this and use other audio modes. Perhaps this is intentional behavior, but to ensure that this gets resolved correctly it may be worth raising this issue with the Oculus team (assuming you haven’t already).

To be noted is that if I try to launch a direct call to another zoom user, the caller (and only he, not the callee as well) can actually change volume successfully.

When you do this, are both the calling and receiving ends using an Oculus Quest device?

If there is any noteworthy difference in terms of meeting configuration that I could apply also to normal meetings, It would be nice to know.

While there are a few audio settings that you can adjust, they primarily target the audio input of the current user. I am not aware of any meeting settings that would alter ability to adjust the audio output in a meeting.

I couldn’t find any info about how to start a direct call anywhere, and I’m not able to decompile the official apk in order to see how it is done.

I’m assuming you are referring to direct calling specific contacts that is done through the Zoom client? Since the Meeting SDK is only focused around in-meeting functionality, this feature is actually outside of the scope of what the SDK is responsible for. If you were to implement such a feature, the SDK would only be involved on the caller side when obtaining the meeting information, and then on the receiving side once the meeting information has been received.

Is it possible maybe to redirect the call audio towards STREAM_MUSIC (which is controllable from Quest) ? This could work too.

We wouldn’t be able to change this across the board, as that would be a breaking change for existing implementations that rely on the current approach. What may be possible is a new flag added to the SDK which would swap to STREAM_MUSIC to better support this use case. We would need to investigate what is causing this before we would be able to consider adding this option.

Thanks!

3

Hello @jon.zoom and thank you for your fast answer.

Perhaps this is intentional behavior, but to ensure that this gets resolved correctly it may be worth raising this issue with the Oculus team (assuming you haven’t already).

I already raised the issue with Oculus, but seeing how this is more application-specific and other VoIP solutions work perfectly fine, they just dismissed the ticket telling me to go directly to the third party library developers.
In fact, I have been experimenting with AWS Chime and Photon as well. While the former has the same exact behavior as Zoom (in terms of cannot changing the volume of a call) the latter has a Unity-specific plugin which circumvents this issue by redirecting the audio stream towards an in-game ad-hoc sound source, which then gets mixed into the main music channel along everything else and is therefore controllable. Other apps like VRChat or the Oculus Party, work very well, which explains why they decided not to go through with my request.

When you do this, are both the calling and receiving ends using an Oculus Quest device?
Yes. In a direct call to specific contacts through zoom clients, I called another Oculus Quest user. The caller could change the volume, the callee could not. In a normal meeting where I would either invite or share the meeting information with the other Oculus Quest user, none of us could change volume.

Since the Meeting SDK is only focused around in-meeting functionality, this feature is actually outside of the scope of what the SDK is responsible for. If you were to implement such a feature, the SDK would only be involved on the caller side when obtaining the meeting information, and then on the receiving side once the meeting information has been received.
A-ha! this explains why I couldn’t find any info about that.
Am I right in assuming that a direct call is basically a meeting which has a short-cut way to invite somebody else? At this point, I’m very curious at how is it possible that the caller can actually change volume, if this is a ‘normal’ meeting which uses the Meeting SDK. There must be something different when creating the meeting or connecting to the audio source, that makes the caller able to change volume. If we could find it, I could use that to start normal meetings as well.

What may be possible is a new flag added to the SDK which would swap to STREAM_MUSIC to better support this use case. We would need to investigate what is causing this before we would be able to consider adding this option.

This would be awesome. I totally understand adding a new flag not to disrupt existing implementations.
I am completely available to cooperate and test.

What would be the next steps then? Should I just wait for more feedback in this post?
Just to recap, either adding a flag to swap to STREAM MUSIC or finding the difference between direct call and normal meeting (so that I could re-use the technique) would be fine.
Let me know, and thank you again for your help.

Massimo

4

Hi @massimo.bortolamei,

I already raised the issue with Oculus, but seeing how this is more application-specific and other VoIP solutions work perfectly fine, they just dismissed the ticket telling me to go directly to the third party library developers.

Got it. Did they offer any insight into why this would only happen with some implementations? Based on your initial post, it was my impression that all audio would be forced into the same channel, but I am now unsure since Oculus support is implying that it is controlled by the implementation.

Yes. In a direct call to specific contacts through zoom clients, I called another Oculus Quest user. The caller could change the volume, the callee could not. In a normal meeting where I would either invite or share the meeting information with the other Oculus Quest user, none of us could change volume.

This is interesting. The core audio component should not behave differently based on how a user joined a meeting. This may be indicative of there being a bug within our client (which also was inherited by the SDK). We’ll need to investigate this further.

Am I right in assuming that a direct call is basically a meeting which has a short-cut way to invite somebody else?

Yes, you are correct. At a high level, I think that the client creates an instant meeting and invites the called user to it.

At this point, I’m very curious at how is it possible that the caller can actually change volume, if this is a ‘normal’ meeting which uses the Meeting SDK. There must be something different when creating the meeting or connecting to the audio source, that makes the caller able to change volume. If we could find it, I could use that to start normal meetings as well.

I am not sure why the way a host starts a meeting would impact the audio output at this low of a level. On the bright side, this tells us that there is in fact a way for the SDK/client to emit Oculus-friendly audio. We’ll just need to see how difficult it will be to propagate this to all users, regardless of how they join a meeting.

What would be the next steps then? Should I just wait for more feedback in this post?
Just to recap, either adding a flag to swap to STREAM MUSIC or finding the difference between direct call and normal meeting (so that I could re-use the technique) would be fine.

I think we will need to do some investigating on our end before we can take any definitive steps. If we need any additional information from you, I will be sure to reach out in this thread. On the other hand, if you have any new findings or questions, you are more than welcome to reach back out. :slightly_smiling_face:

Thanks!

5

Hi @jon.zoom and thank you again for your help.

Got it. Did they offer any insight into why this would only happen with some implementations? Based on your initial post, it was my impression that all audio would be forced into the same channel, but I am now unsure since Oculus support is implying that it is controlled by the implementation.

Sorry I might have been confusing in my explanation. Quest directs everything towards the music stream by default, no matter the app (at least that is my understanding). But since they have other VoIP apps such as VRChat and the Party feature where volume works well, they just said to sort it out with whoever implemented the library, so that they could fix the issue on their side, and not on Oculus Side (altough one could argue that their particular approach does create a lot of problems…).

It is indeed possible to fix this issue with unity-native code, in fact as I briefly explained up here, Photon (another networking library ) developed a unity-specific plugin which in my understanding takes the audio bytes transferred through the network, and writes those into an audio source directly in game (audio source is a unity component). This results into the audio being directed into the main mixer of the unity app and is super controllable. They basically avoided doing what most do in Android native code (with AudioTracks etc) and decided to develop a unity-native solution.
But given that I’m working on a multi-platform solution where we have a WebVR-capable WebApp which communicates with a unity-based Oculus Quest app, I’m looking for a much more scalable approach.

I am not sure why the way a host starts a meeting would impact the audio output at this low of a level. On the bright side, this tells us that there is in fact a way for the SDK/client to emit Oculus-friendly audio. We’ll just need to see how difficult it will be to propagate this to all users, regardless of how they join a meeting.

Yeah ! I think this is actually one of those good bugs where you can say “It’s a Feature!”.
Can’t wait to hear back from you after your investigation.

Cheers,
Max

6

Hi @massimo.bortolamei,

Thanks for clarifying around the audio behavior on the Quest. At this point we’ll just need to investigate the behavior on our end to see why this seemingly does not apply to all types of audio output.

It is indeed possible to fix this issue with unity-native code, in fact as I briefly explained up here, Photon (another networking library ) developed a unity-specific plugin which in my understanding takes the audio bytes transferred through the network, and writes those into an audio source directly in game (audio source is a unity component).

This is definitely not the sort of workaround we want you to be forced to implement to be able to properly affect the audio level from the SDK. I’m pretty confident that we will be able to come up with a better solution than this. :slightly_smiling_face:

Yeah ! I think this is actually one of those good bugs where you can say “It’s a Feature!”.

Ha, it certainly seems that way!

Thanks!

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.