I'm using CocoaLibSpotify and the SPPlaybackManager to stream Spotify music to my app. It works very well overall, but I'm experiencing some issues with the playback during other network activity.
Procedure:
(During audio playback) I'm firing a regular ASIHTTPRequest to a server.
When the request has finished, I'm making a number of Spotify searches using SPSearch.
On many devices (in particular iPhone 3GS), I'm getting massive "stuttering"/"skips"/"pauses" in the playback while the Searches are performed.
Earlier, I used regular ASIHTTPRequests instead of the SPSearch class, so I'm quite sure it's got to do with the overall network activity.
Also, the playback issues may appear while doing some other network activity on the device, i.e. loading a number of emails in the Mail app.
Threading?
I'm guessing this is some kind of threading issue (i.e. the audio is played back on the main thread or something), but I'm not sure exactly how to approach the issue... I've tried invoking SPPlaybackManager#playTrack:: on a background thread, but I guess the setup wasn't 100% correct (since the issues remained).
Does anyone have any pointers as to how I should move forward?
Both the audio delivery and audio playback in the classes supplied with CocoaLibSpotify are run on (different) background threads. However, SPPlaybackManager is only intended to be an easy-to-follow example of dealing with audio playback using Core Audio - it hasn't been tested for, nor is it intended for, use during high CPU load and/or in environments very tight on resources.
All I can do is point you towards the standard debugging tools such as Instruments to trace and profile what's going on.
Related
Can I build an iOS app that uses the camera (even if it doesn't take pictures/video) while the app is in the background?
If not, why? Where has Apple come out with this information? I have seen similar questions and answers, but none with direct proof from Apple.
For example, if I wanted to make an app that, while in background, can keep track of how many trees our phone encounters through the day through object recognition software.
The camera stops functioning when app moves to background and I have found this apple doc that supports the claim. Hope this will help you.
AVCaptureSessionInterruptionReasonVideoDeviceNotAvailableInBackground
Camera usage is prohibited while in the background. If you attempt to
start running a camera while in the background, the capture session
sends an AVCaptureSessionWasInterruptedNotification with this
interruption reason. If you don't explicitly call the stopRunning
method, your startRunning request is preserved, and when your app
comes back to foreground, you receive
AVCaptureSessionInterruptionEndedNotification and your session starts
running.
No, as soon as your app enters the background (even the built-in camera app), the camera stops recording.
This is done primarily because the camera consumes a great deal of power and generates a lot of heat. If you were to record a 15 minute video with an iPhone, you will notice both pretty quickly.
Combine running CV software, and you will drain the battery of any device in short order.
It's good that apple doesn't allow because it increases risk of apps capturing your moments from background without making you notice. Thus risk to privacy.
I'm currently working on an iOS app which involves recording and uploading videos (from the built-in camera) to a server.
It all works reasonably fine and dandy, but for a new version, the customer has requested a new feature: continuing this process without needing the app to up on the screen, and active.
At present, you record a video, it's stored as an MP4 on the file system, and a background thread uploads the file to the server. This all happens while the app is open, culminating in a screen which essentially tells you to wait until the process has finished.
If you press the home button to "minimise" the app (I'm not fluent in iOS terminology, forgive me), currently all upload processes are paused. The customer wants to have it so that you can minimise and do something entirely different as this process continues, with a notification being shown once the uploads are complete.
My understanding is that iOS offers a few special cases for downloading, streaming music and location stuff.
Supposedly once upon a time you could obtain ten minutes or so of background time while your app was minimised to finish tasks - after which time iOS would forcefully pause everything until the app was front and active again. This apparently has been changed in newer versions of iOS meaning you can't rely on a specific figure anymore - but ten minutes wasn't really good enough anyway.
I can think of hacky ways of abusing the above features but I'm half-concerned Apple might discover this during the iTunes submission process. Really I'm looking for a cleaner method - how do I continue uploading videos while the app is minimised?
I am assuming there's a solution - Dropbox can handle this situation?
Surprisingly I got somewhere with this, despite quite a few guides suggesting it was virtually impossible and even Dropbox admitting it has to do a hacky location-based thing.
The code was utilising the NSURLSession class, and for uploading, you use its uploadTaskWithStreamedRequest() method, passing an HTTP request and getting a NSURLSessionUploadTask instance in return.
What wasn't immediately clear to me, however, was that "resuming" that task led to files being uploaded independently from the rest of the app, i.e. when the app is minimised, this task continues until it either completes or iOS forces it to pause.
In a sense I had already achieved what I asked for without realising, however this task can still be interrupted by iOS after a few seconds. The rest of the app is also paused, so communication is hampered until the app is brought back to the front again.
The trick is these two methods:
uploadTaskID = UIApplication.sharedApplication().beginBackgroundTaskWithExpirationHandler({})
and
UIApplication().sharedApplication().endBackgroundTask(uploadTaskID)
with these in place, any code after the "begin" function will run regardless of whether the app is minimised, and will do so until the "end" function is called. With a bit of tweaking, I've been able to get files to upload sequentially and post a notification when the process is done.
I haven't seen this solution be hinted at so it might be a bad idea, but it seemingly works.
I'm developing an background (daemon) application that will schedule a task on an exact time. For example, do something at 3 PM, or it can be do something after 3 hours. I've tried NSTimer and scheduling NSThread, but it does not do the task at the time I schedule because iPhone is in deep sleep.
Note that this is an application on a jail-broken device and run as a daemon, so it doesn't have UIApplication instance.
I had the same problem with my daemon. I couldn't find any working method for scheduling device wakes. Instead I prevent it from ever falling in a deep sleep by infinitely playing audio file with silence. That way you don't need IOKit to cancel sleep and your device will stay awake. I can't find the code now but it's very simple - a few calls to AVAudioPlayer. You also need to setup audio session for audio playing and mixing. It's all public and very well known APIs so there shouldn't be any problems implementing that.
There are problems with it. For example, playing audio file will reroute audio to the device receiver. By default audio is playing through the speaker so you need to take care of that. You also need to detect when the screen is turned on/off because device will not sleep when the screen is turned on. When the screen is turned off you start playing silence. When it's turned on you stop it. That will also solve mixing problems with other apps that are trying to play audio.
Unfortunately I don't have any code with me right now to show you some examples. I can add the code later if need it.
Im using MPMoviePlayerController to stream audio from a server, but after playing the audio for more than two minutes, the audio starts to stop and resume alot, im streaming more than one file one after one, so because of the interruption, some of the audio files are being skipped with those two console messages:
Took background task assertion (38) for playback stall
Ending background task assertion (38) for playback stall
I'm losing a lot of tracks because of this error.
for the first while, i thought that was a memory issue, but the console shows that each time a loose a track, it print those messages,
Check your network connectivity and the stream encoding.
This console output pretty much says exactly what your problem is; the stream dries out of content and could not keep up playing without interruption.
Either your network connection is unstable or the content is encoded in bandwidths that are far too high for your network connection.
For clarification; even if your local internet peering is offering high bandwidths, you should still check the bandwidths of the entire route. For example, you could try to download the streamed files via your browser for testing the throughput.
Are you trying it on a simulator or a device? It may be a simulator issue.
Also, on device, try streaming through multiple networks, e.g., LTE, wifi, etc., see if there is any difference
I am using AVPlayer to play an audio stream, and it's possible to keep it playing in the background. I'm wondering how could I handle a situtation where the user loses internet connectivity, so that I could provide some feedback or maybe try to re-establish the playback after some seconds.
EDIT: I know that the question regards AVPlayer, but if you have an answer with MPMoviePlayerController it might be useful as well. Right now, by using MPMoviePlayerController, I'm trying to get the MPMovieFinishReasonPlaybackError case of the MPMoviePlayerPlaybackDidFinishReasonUserInfoKey, by subscribing to the MPMoviePlayerPlaybackDidFinishNotification but if f.e. my audio is playing in the background and I turn airplane mode on, I never get this notification; I only get MPMovieFinishReasonPlaybackEnded, and I don't know how to separate that from the case that the user stops the audio himself.
I tried looking around for the actual source but I remember reading somewhere that if the audio playback stops (for whatever reason) it kills the background thread. The person writing about the issue talked about possible feeding the stream some empty audio content to keep the thread alive. You might be able to send a local notification from a call back error notifying the user that the audio experienced an error and will have to be manually restarted from within the application. Haven't played around with the API enough to know which callback is the best one to use in this case. If I find the link I'm looking for I'll update.
EDIT: Here's Grant Pannell's take on audio streaming and multitasking.