Re: AudioDeviceGetCurrentTime after headphone plug/unplug
Re: AudioDeviceGetCurrentTime after headphone plug/unplug
- Subject: Re: AudioDeviceGetCurrentTime after headphone plug/unplug
- From: Jeff Moore <email@hidden>
- Date: Wed, 17 Jan 2007 12:01:51 -0800
The amount of churn that gets caused by plugging in headphones to a
device really depends on the device. For some devices, it is totally
transparent. For others, it requires a massive reconfiguration of the
hardware. From the sound of it, you are probably talking about the
built-in hardware on some of our machines. That hardware does indeed
cause a lot of churn, including stopping and restarting IO which
causes the timeline to change.
Probably the easiest way to address this is to use the HAL output
unit, AUHAL, that can be configured so that it's time stamps are
continuous even when the HAL's time stamps are discontinuous. Short of
that, you'll need to implement the math that does the same thing.
Fortunately, the code that AUHAL uses to do this is in our SDK in the
form of the AUTimestampGenerator class.
On Jan 17, 2007, at 7:47 AM, Bjorn Roche wrote:
Hey all,
I'm the CoreAudio maintainer of the PortAudio (www.portaudio.com)
portable audio I/O library. A bug in PortAudio recently came to my
attention: when you plug or unplug headphones during playback, the
timing information gets screwed up. PortAudio retrieves timing
information from CoreAudio in a variety of ways, however, the
problem in question seems to be with AudioDeviceGetCurrentTime.
Since the AudioDeviceGetCurrentTime changes when plugging/
unplugging headphones, I presume that CoreAudio considers plugging/
unplugging the headphones to be a device change, so, presumably I
can monitor for that and update my internal variables as
appropriate. Short of mutexes/spin-locks, though, it would not be
possible to guarantee that both my internal variables and
AudioDeviceGetCurrentTime are always referring to the same thing --
especially from the perspective of other threads. I'm not sure it's
a good idea to use spinlocks or mutexes in the device-change
callback, either, even if contention is very low. So the question
is: how do I provide a continuous and accurate reflection of the
current device's time, even when the headphones are plugged/unplugged?
Sorry if I haven't explained the question adequately -- it's been a
while since I've looked at this code or even thought about these
issues, so I'm a little rusty.... any thoughts on this would be
helpful.
The code in question can be viewed here:
http://www.portaudio.com/trac/browser/portaudio/branches/v19-devel/src/hostapi/coreaudio/pa_mac_core.c
lines 1419-1458 are most relevant. (as you'll see from my comments,
I was never too sure of this stuff in the first place!)
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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