Restarting a remoteIO unit soon after stopping it
Restarting a remoteIO unit soon after stopping it
- Subject: Restarting a remoteIO unit soon after stopping it
- From: <email@hidden>
- Date: Thu, 14 Oct 2010 19:18:32 +1300
- Thread-topic: Restarting a remoteIO unit soon after stopping it
I'm having an issue with the remoteIO where starting the audio output
shortly after stopping it results in the audio unit not working
properly.
The general structure is that I've got a render callback attached to the
remoteIO device, and start the audio unit with AudioOutputUnitStart().
Once all the audio is done, AudioOutputUnitStop() is called from within
the render callback, and afterwards a flag is set to indicate that the
audio unit has been stopped.
If I then start the audio output again with AudioOutputUnitStart(), one
of two things happens - if it's more than about 50 ms after the call to
AudioOutputUnitStop() returned, then everything works great. If,
however, it's done sooner than this threshold, then the call to
AudioOutputUnitStart() succeeds, the kAudioOutputUnitProperty_IsRunning
property gets set to true, but the render callback is either never
called or only called once.
My guess here is that it's related to the fact that it takes some time
from the end of the AudioOutputUnitStop() call to when the device is
really stopped (buffers flushed plus whatever other internal state is
cleaned up), and calling AudioOutputUnitStart() during this time results
in breakage. The workaround in this case would be to simply track the
number of samples sent out during the last two render callbacks, the
time at which AudioOutputUnitStop() returned, and make sure (via a
sleep) that AudioOutputUnitStart() doesn't get called before this time
plus a little margin. It feels a bit hackish though.
Another alternative is just to not call AudioOutputUnitStop() from
within the callback. I've kept away from this approach as I've got in my
notes that on some iOS/OS X versions it doesn't block at all (so further
callbacks can be made after the function returns, which obviously
doesn't help very much), and may or may not drop buffers. However, an
earlier post by Jeff Moore a few years back indicates that it should
block until the HAL stops, which presumably is good enough? Tests seem
to indicate that it is sufficient on the latest OS X/iOS, but there
doesn't seem to be any documentation about this behaviour.
So, is there any documentation/guarantee regarding the way
AudioOutputUnitStop() works from inside and outside render callbacks,
with recent (for some value of recent) OS X/iOS versions? Mainly with
regard to when it is safe to call AudioOutputUnitStart() again, and with
respect to whether buffers previously returned (or being filled) by the
render callback actually make it to the speaker.
Cheers,
Michael
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden