Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] expose disableAudioProcessing publisher option #237

Open
snobear opened this issue Feb 24, 2019 · 5 comments
Open

[feature request] expose disableAudioProcessing publisher option #237

snobear opened this issue Feb 24, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@snobear
Copy link
Contributor

snobear commented Feb 24, 2019

Feature Request

Description

When publishing high-quality audio streams, disabling audio processing is recommended per Opentok docs.

For our use case, we have users performing live music, e.g. with an acoustic guitar. Even with the audioBitrate at the max of 128000, we are still experiencing poor-sounding audio. Certain frequency ranges on the guitar sound like it has an "underwater" effect to it. When we had used the js web library, we were able to mitigate this by disabling the audio processing (echo cancellation, automatic gain control, and noise suppression).

Proposal

Add a disableAudioProcessing parameter for OTPublisher. Default to false.

Links / references

See disableAudioProcessing in https://tokbox.com/developer/guides/audio-video/js/#audio-tuning.

@snobear
Copy link
Contributor Author

snobear commented Feb 24, 2019

@msach22 I was going to start looking into this, but please let me know if there are limitations on the client side that would prevent this from being possible. I'm assuming audio processing is handled on the Tokbox servers, so we just need to have the option exposed in this RN lib to pass it along.

@snobear
Copy link
Contributor Author

snobear commented Feb 24, 2019

On a related note, is it possible to confirm that our audioBitrate settings are being honored? I was looking through the tokbox session inspector logs, but I'm not seeing any logs on what settings are in place.

@msach22
Copy link
Contributor

msach22 commented Feb 25, 2019

@snobear Thanks for filing the feature request. Unfortunately, there is no easy way of disabling the audio processing because it's not an API that we have for iOS or Android. We would have to write custom audio drivers for both iOS and Android to make this functionality possible.

As for the audioBitrate, can you please email me the sessionId so I can check out the audioBitrate settings for you?

@snobear
Copy link
Contributor Author

snobear commented Feb 26, 2019

@msach22 thanks for the reply. I sent you an email with the session ID.

We'll be doing some more testing on audio quality with various devices tonight to see how guitars and other instruments sound. Based on my experience with browser-based WebRTC libs in the past, we've had to disable noise cancellation and other audio processing. So, sounds like we will need to implement custom audio drivers for ios and android. I see some basic info in these articles:

https://tokbox.com/developer/tutorials/ios/custom-audio-driver/
https://tokbox.com/developer/tutorials/android/custom-audio-driver/

It sounds like you have to implement all of the low level audio functions just from a quick read of those articles. Is there a way to just inherit all the defaults and just disable audio processing? Or maybe the default doesn't have a handy flag to easily switch off...

Perhaps we can hop on a call if you're free and give us your thoughts on that, and how to integrate it with the RN lib here, or at least in our own fork.

@msach22
Copy link
Contributor

msach22 commented Feb 26, 2019

@snobear Thanks for sharing the sessionId, I'll reply via email on that one shortly.

Yes, for Custom Audio Drivers we have to implement the low level audio functions. Unfortunately, there is no other way around it at this time. I'm happy to take a PR and get that added to main library as well where we can expose this via prop and the native layer can handle all of the custom audio work. We can also hop on a call and discuss if you'd like :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants