Unpausing a track while in the background throws an AudioQueueStart error

[steveluscher]

As part of my application's regular operation, it may need to pause a track, wait for a bit, and then unpause it. It needs to be able to do this while in the background as well as the foreground.

If I try to pause a track while the app is in the background then unpause it at a later time, the SDK throws an AudioQueueStart error and stops playback. No such error is thrown when the application is running in the foreground.

I have put together a test case for you, based on the hello-ios-playback repository.
https://github.com/steveluscher/hello-ios-playback/compare/background_stream_error

Simply run the thing, tap play, send the app to the background using the home button, then watch the console.

[rknLA]

Strange. The SDK appears to behave correctly (in simulator at least) for iOS 5.0, but does not resume playback (as reported) in iOS 6.0 and iOS 6.1.

Looking at the code, I expect this is an issue with threading and our unfortunate incompatibility with Grand Central Dispatch. Until we support GCD, I don't think there's a really Good™ solution to this, but I'll see if I can come up with a workaround for you until we get there.

[steveluscher]

Oh dear. I hadn't even tried to run the test case in the simulator.

In the simulator, it gets even weirder. After the 5 second pause has elapsed, and [[self getPlayer] togglePause] is called, rdioPlayerChangedFromState: reports that the player has gone from RDPlayerStatePaused to RDPlayerStatePaused:

(lldb) po fromState
$0 = RDPlayerStatePaused [no Objective-C description available]
(lldb) po state
$1 = RDPlayerStatePaused [no Objective-C description available]

Despite the fact that the player reports itself as being paused, the second track resumes play on the iOS 5.0 simulator, but not on the iOS 6.1 simulator. This is true whether the app is in the background or the foreground, regardless of simulator version.

In any case, device behavior is quite different. I've only been able to replicate the AudioQueueStart error on a device.

	Transitions properly from RDPlayerStatePaused to RDPlayerStatePlaying	No AudioQueueStart error	Playback resumes
5.0 sim (foreground)	🚫	👍	👍
5.0 sim (background)	🚫	👍	👍
6.1 sim (foreground)	🚫	👍	🚫
6.1 sim (background)	🚫	👍	🚫
6.1 device (foreground)	👍	👍	👍
6.1 device (background)	🚫	🚫	🚫

[rknLA]

Ok. At this point, I think I need to set aside a whole day devoted to this. I suspect that the version of AudioStreamer we're using is buggy in complex thread situations (potentially related to object retention and/or block scoping?).

I should be able to allot more time to this next week.

[steveluscher]

It's funny, too; though I am using GCD in my test case (via dispatch_after and NSOperationQueue) to do stuff like "wait for 5 seconds", or to ensure that the player gets paused and stays paused without recursing deeply into rdioPlayerChangedFromState, I'm trying to keep the thread situation simple by making sure only to call RDPlayer methods from the main queue.

Thank you for taking the time to help.

[steveluscher]

Yeah; there seem to be a lot of people taking a dump on AudioStreamer on GitHub with regard to its state handling (mattgallagher/AudioStreamer#58, mattgallagher/AudioStreamer#68), backgrounding (mattgallagher/AudioStreamer#8), race condition-y behavior (mattgallagher/AudioStreamer#1, mattgallagher/AudioStreamer#16), and just generally about it appearing to have been abandoned (mattgallagher/AudioStreamer#45).

Trolling through the AudioStreamer issues, I wonder if mattgallagher/AudioStreamer#55 and mattgallagher/AudioStreamer#35 are related to the Rdio SDK pause issues, like #82 (this one) and #64?

There are a lot of upstart audio streamers around GitHub. Audjustible seems to tout the kind of features that a service like Rdio is likely to require (“buffered and gapless playback,” “optimised for low CPU/battery usage,” “[extendable] DataSource to support adaptive buffering, encryption, etc…”)

[dasevilla]

The latest iOS SDK contains many fixes to streaming. If you can still reproduce this issue, please reopen.

http://blog.rdio.com/developers/2015/06/ios-sdk-v302.html