#5886-Prevent Crash on Airplaying Audio Attachment #6058
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rplay. This doesnt actually prevent playback over airplay, but it prevents the resource loading length from being much bigger than a UInt32 max value (cherry picked from commit c46d9c607273049991f9a5357d0cd7470ec8cc06)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contributor checklist
Description
This PR
fixes #5886by preventing AudioPlayers AVPlayer from externally playing. Weirdly (this will be explained later) this doesn't prevent audio from from being airplayed, but it prevents the dataRequests requested data length from being bigger than a UInt32, which was causing this crash to happen. I tested this by airplaying Spotify from my iPhone 12 to my Mac Mini and playing an audio attachment.My hypothesis:
While working on this bug, I noticed that in the AudioPlayer class, we are using the AVPlayer class instead of the AVAudioPlayer class. I think the root cause of what is causing this bug to happen is that when we switch to using AirPlay, the system sees that the ResourceLoadingRequest is coming from an AVPlayer, something that is designed to play both video and audio, and then subsequently requests too much space for video content, something that will never come as were using only audio in our AVAssets. By disallowing external playback, we prevent any video content from being played outside the app (even though we don't have any) and subsequently the space for video content never gets allocated. I think by switching the AudioPlayers AVPlayer to AVAudioPlayer will solve this problem.