4

I'm doing some audio streaming with iOS 7's Multipeer Connectivity framework. The streaming works well, but when I put the app on background it stops working.

Someone can tell me if this is a framework limitation, or I'm doing something wrong?

  • And, if it is a framework limitation, is it possible to do something to avoid this?

  • Can I use Background Tasks, to keep streaming and music working on background?

  • Is possible do this? If is not possible, do any alternatives exist for MultiPeer audio streaming between iOS devices?.

I´m using this example: https://github.com/tonyd256/TDAudioStreamer.

Explained on this page: http://robots.thoughtbot.com/streaming-audio-to-multiple-listeners-via-ios-multipeer-connectivity.

Thanks a lot!

Joel Fischer
  • 6,521
  • 5
  • 35
  • 46
Gonzalo Bahamondez
  • 1,371
  • 1
  • 16
  • 37
  • any update on the subject? Did your app got rejected during the review? I read on at least one example app that streamed audio to multiple iOS devices and got removed from App Store. – Wladek Surala Jul 23 '14 at 17:28
  • I have used TDAudioStreamer but its not playing the audio its just displaying the image and info of song file. Can you suggest me how did you implemented ? – Aadil Keshwani Apr 30 '16 at 11:21

2 Answers2

3

On the Apple documentation for playing audio in the background (scroll down a bit). Some relevant paragraphs:

When the UIBackgroundModes key contains the audio value, the system’s media frameworks automatically prevent the corresponding app from being suspended when it moves to the background. As long as it is playing audio or video content or recording audio content, the app continues to run in the background. However, if recording or playback stops, the system suspends the app.

You can use any of the system audio frameworks to work with background audio content, and the process for using those frameworks is unchanged.

This means that iOS should recognize that you're playing audio through Core Audio, and keep your app unsuspended, as long as you've correctly configured your app for playing audio in the background.

Because your app is not suspended while playing media files, callbacks operate normally while your app is in the background. In your callbacks, though, you should do only the work necessary to provide data for playback. For example, a streaming audio app would need to download the music stream data from its server and push the current audio samples out for playback. Apps should not perform any extraneous tasks that are unrelated to playback.

You should be able to operate normally as long as your app is still playing audio, and is allowed to do what it needs to in order to continue playing audio. This means that you should be able to continue to use MPC in the background to receive the audio data and play it.

Be sure to read the entire documentation on the subject, especially regarding Audio Sessions.

Community
  • 1
  • 1
Joel Fischer
  • 6,521
  • 5
  • 35
  • 46
  • You have all the reason, Really Thanks!. mmm i need wait 19 hours to bring your points :D! – Gonzalo Bahamondez Feb 20 '14 at 19:15
  • Is this still accurate in 2019? My understanding is that without the "voip" key in UIBackgroundModes, network activity (using MultipeerConnectivity) may be blocked after ~10 minutes of background operation. – Petrus Theron May 24 '19 at 09:34
2

iOS devices get limited cpu cycles for explicit purposes when they have been backgrounded by the user.

According to Apple's documentation on multitasking and execution in the background, the following types of apps are supported, but have to be explicitly declared:

  • Apps that play audible content to the user while in the background, such as a music player app
  • Apps that record audio content while in the background.
  • Apps that keep users informed of their location at all times, such as a navigation app
  • Apps that support Voice over Internet Protocol (VoIP)
  • Apps that need to download and process new content regularly
  • Apps that receive regular updates from external accessories

Your case falls under Apps that play audible content to the user while in the background, such as a music player app. You can find more information from the link provided above.

JuJoDi
  • 14,627
  • 23
  • 80
  • 126
  • The background mode you described is for background downloading over the network to keep data up to date. It is not for something like multipeer streaming. This will only be invoked once every few hours to keep content up to date in the app, irregularly and when determined by the iOS system itself. – Joel Fischer Feb 20 '14 at 15:20
  • Thanks, but if is not possible with MultiPeer Connectivity framework, what else can i do? are some other alternatives for stream music to multiple devices at the same time? i´m reading a lot, but i cant find the correct way. – Gonzalo Bahamondez Feb 20 '14 at 15:27
  • Is the data always going to originate from one device? – JuJoDi Feb 20 '14 at 15:29
  • The idea is originate the data for any device connected to multipeer session , but if you know one way for do this from one device, anyway , can be useful for me. – Gonzalo Bahamondez Feb 20 '14 at 15:32
  • Well if you are okay with only originating from one device, then you could use a webserver on the "host" device. Otherwise, I'll think you may be out of luck with MPC. You could try using the audio background mode, but it doesn't appear your app falls into a covered use case (local, URL, Airplay). It's worth a try, though. – Joel Fischer Feb 20 '14 at 15:47
  • Yes, i was thinking in the option of webserver on the device (CocoaHTTPServer), and stream data over http or something like this, but i need generate a local hostpot for do this? , i was reading about this, but in some apple docs, says that is not posible do this from code, and this way drain a lot of battery, i guess the unique way to do this is manually by the user. what do you think? – Gonzalo Bahamondez Feb 20 '14 at 16:07
  • Standby :D Joel has an answer that shouldn't see you scrapping much of your work. – JuJoDi Feb 20 '14 at 16:22