there’s an audio application which streams files via network, everything works fine but one thing. To play the next track automatically in the background the CFReadStream is initialized (i can see it in the log) after the AudioQueueStop is called, but the callback is never called (edit: actually is called once) until the app enters foreground. Piece of code for stream init:
//also tried main runloop just for test, no luck
CFReadStreamScheduleWithRunLoop(stream, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);
The wired thing is that the app is functional after the queue is stopped, the stream is being initialized but the callback is properly called only if the stream was initialized in the foreground mode. Here is a piece of code for callback:
CFReadStreamSetClient(stream,
kCFStreamEventHasBytesAvailable | kCFStreamEventErrorOccurred | kCFStreamEventEndEncountered,
MyReadStreamCallBack,
&context);
On the other hand, the callback is called when the application is in the background and the next track is triggered not automatically but with the app-delegate (with the same function).
I don’t completely understand the difference between that three cases, please help.
Edit.
OSStatus status = AudioFileStreamOpen(self, MyAudioListener ...
MyAudioListener callback is being called while MyReadStreamCallBack is called just once.
Edit 2
the ReadStream callback is most often not being called even once, one time is the maximum of what i was able to see.
On the other hand, and that drives me to misunderstanding of what’s happening, after the previous AudioQueue is stopped and the next track is a local file, then another AudioQueue is opened, it reads the file with AudioFileReadPackets and i don’t have to awake the application from background to start the next track playback as it plays itself in the background.
An Audio Queue will continue run in the background, given the approprate background modes. But once stopped, it seems that an Audio Queue will not start running in the background. The one callback is probably just to prime the buffer so the the queue can start immediately after being brought to the foreground.
The only solution I’ve found is to not stop the previous Audio Queue when in the background, but to somehow feed new audio data to the old Audio Queue left running, without underflowing any callbacks in between.