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

Audio re-routes to earpiece after Recording: workaround does not play well with other libraries (iOS) #20943

Closed
taylorkangbeck opened this issue Jan 24, 2023 · 4 comments
Labels
needs review Issue is ready to be reviewed by a maintainer stale

Comments

@taylorkangbeck
Copy link

Summary

Issues with Recording causing audio to permanently reroute to the earpiece only (not the speakers) has been worked around, and the docs were updated:
#19220

However, this approach does not play well with other audio libraries. I am using react-native-track-player, and the provided workaround of setting allowsRecordingIOS: false after recording has no impact. After recording with Expo, all subsequent audio played via react-native-track-player is routed through the earpiece.

I did find a (non-ideal) workaround: after recording with Expo, if I then play a sound with Expo, audio will route back to the speakers, and subsequent plays with react-native-track-player also go through the speakers as expected. I tried playing an empty wav file (no audio frames), but it seems that it requires actual sound to be played.

If this is not a bug and is an intended side effect, then I think more explicit APIs to reset the audio routing to a previous state are necessary (maybe just an option to stopRecording).

What platform(s) does this occur on?

iOS

Environment

expo-env-info 1.0.5 environment info:
System:
OS: macOS 12.6
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.17.0 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 8.15.0 - /usr/local/bin/npm
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
IDEs:
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
npmPackages:
expo: ^46.0.16 => 46.0.16
react: 18.0.0 => 18.0.0
react-dom: 18.0.0 => 18.0.0
react-native: 0.69.6 => 0.69.6
react-native-web: ~0.18.7 => 0.18.9
npmGlobalPackages:
eas-cli: 3.0.0
expo-cli: 6.0.8
Expo Workflow: managed

Minimal reproducible example

expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 12.6
      Shell: 5.8.1 - /bin/zsh
    Binaries:
      Node: 16.17.0 - /usr/local/bin/node
      Yarn: 1.22.19 - /usr/local/bin/yarn
      npm: 8.15.0 - /usr/local/bin/npm
    Managers:
      CocoaPods: 1.11.3 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
    IDEs:
      Xcode: 14.2/14C18 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^46.0.16 => 46.0.16 
      react: 18.0.0 => 18.0.0 
      react-dom: 18.0.0 => 18.0.0 
      react-native: 0.69.6 => 0.69.6 
      react-native-web: ~0.18.7 => 0.18.9 
    npmGlobalPackages:
      eas-cli: 3.0.0
      expo-cli: 6.0.8
    Expo Workflow: managed
@taylorkangbeck taylorkangbeck added the needs validation Issue needs to be validated label Jan 24, 2023
@brentvatne brentvatne added needs review Issue is ready to be reviewed by a maintainer and removed needs validation Issue needs to be validated labels Feb 22, 2023
@FRCassarino
Copy link

Same issue here.

@jacklj
Copy link

jacklj commented Mar 26, 2023

Same issue with recording audio using expo-av and then playback with react-native-track-player.

I've partially fixed it by calling await Audio.setAudioModeAsync({ allowsRecordingIOS: false }) before calling stopAndUnloadAsync() when ending the recording. This means subsequent audio playback with react-native-track-player does go through the phone speakers, not just the earpiece.

However, there's still a problem - the playback controls in the Control Centre and Lock Screen still don't appear.

@github-actions
Copy link
Contributor

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

@github-actions github-actions bot added the stale label Jun 24, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jul 1, 2023

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.

@github-actions github-actions bot closed this as completed Jul 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs review Issue is ready to be reviewed by a maintainer stale
Projects
None yet
Development

No branches or pull requests

4 participants