Re: DefaultOutputDevice timestamps
Re: DefaultOutputDevice timestamps
- Subject: Re: DefaultOutputDevice timestamps
- From: email@hidden
- Date: Tue, 23 Oct 2001 01:22:54 -0500 (CDT)
Sorry, I guess I should have included part of the original pair of
messages. Basically the problem I'm having is that I'm outputting to the
AudioDevice returned by the
AudioHardwareGetProperty(kAudioHardwarePropertyDefaultOutputDevice,
&count, (void *) &device);
and in my callback method the AudioDevice sets the
kAudioTimeStampHostTimeValid in the mFlags field in the inOutputTime
parameter to true but the the inOutputTime->mHostTime field is only
updating once per couple of minutes after the callback is called many,
many times. I'm trying to figure out why the inOutputTime field isn't
updating as I want to use that for synchronization of output and
resynchronizing my waveform generating waveforms (btw, what does one
use as a replacement for inOutputTime when dealing with AudioUnits?). What
I meant by "the responsible party" was whatever might be causing
the AudioDevice to update the inOutputTime so rarely. I would assume
that if it's my fault then it would be in the start or setup method from
the previous message of mine as they would be the ones to affect the
AudioDevice before playback (in other words, I doubted the callback method
would need to set a parameter on the AudioDevice to make the mHostTime
in the inOutputTime update in playback).
Thanks for the point about asynchronous play but in this case the
isPlaying boolean is only there to eliminate redundant calls to setup()
and start(), not to determine whether the class' callback method actually
plays or is thought to be playing [I may have left in a misleading
comment from the original source] so I think the asynchronous nature of
the audio system doesn't affect that parameter. I'll have to figure out
how to work in the listener for the kAudioDevicePropertyDeviceIsRunning
when the need arises - luckily right now every thing that outputs audio,
except for the overall controller/mixer is happily ignorant of everything
else so I'm not worried about synchronization outside of the each classes'
independent ability to sync with the inOutputTime. I guess plans for
future architecture haven't been considered directly under the
requirements of an asynchronous architecture and I will definitely do so
when the time comes (I'm working in small steps, a la extreme
programming).
Thanks,
Ben
On Mon, 22 Oct 2001, Jeff Moore wrote:
>
on 10/22/01 2:59 AM, email@hidden <email@hidden> wrote:
>
>
> If an AudioDevice gives me AudioTimeStamps
>
> with the kAudioTimeStampHostTimeValid flag set to true in the mFlags
>
> variable, shouldn't that guarantee me that the time is
>
> indeed valid? I'm still obviously confused by why this isn't working when
>
> it says it should be.
>
>
I guess I came in the middle of this conversation.
>
>
What exactly isn't working?
>
>
For devices that have output, the inOutputTime argument of your
>
AudioDeviceIOProc is the time stamp for when the data in outOutputData is
>
going to hit the wire. Note that you cannot modify this value. It is for
>
your information only.
>
>
For device's that don't have output, the inOutputTime argument will be all
>
zeroes and should be ignored.
>
>
> In the above, I eliminated my error handling code and some other things
>
> which weren't directly related and would be more confusing. Right
>
> now I'd assume my callback can't be the responsible party as it
>
> only reports the AudioTimeStamps and outputs data. Anyway, any
>
> advice appreciated.
>
>
I don't understand. Responsible party for what?
>
>
One problem in your code I see already is that you assume that
>
AudioDeviceStart is synchronous. It is not. You should wait until you
>
receive a notification for kAudioDevicePropertyDeviceIsRunning before
>
setting the value of your isPlaying member.
>
>
This brings up an interesting point that I've seen hurt otherwise good code.
>
>
Just about everything in the HAL is asynchronous. In particular, starting,
>
stopping, and changing the format are asynchronous. This is very different
>
from the way things work on 9. You should structure your code such that you
>
only update your engine's state from the notification. This has the added
>
benefit of making your engine friendly to the rest of the processes you are
>
sharing the machine with. Plus, it's the only way to know certain things
>
like when the user unplugs a USB device.
>
>
--
>
>
Jeff Moore
>
Core Audio
>
Apple
>
_______________________________________________
>
coreaudio-api mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/coreaudio-api