Re: Coreaudio-api Digest, Vol 1, Issue 72
Re: Coreaudio-api Digest, Vol 1, Issue 72
- Subject: Re: Coreaudio-api Digest, Vol 1, Issue 72
- From: "Roni Music" <email@hidden>
- Date: Fri, 12 Nov 2004 22:27:01 +0100
Jeff,
Thanks for your answer!
It explains things and I also relearned what we all knows - never trust others code, at least not without understanding what it does ;-)
I checked the ComplexThruExample at developer.apple.com and it turned out there was a change exactly related to my problem
//changed: 3865519 11/10/04
if (delta < 0.0)
This->mInToOutSampleOffset -= delta;
else
This->mInToOutSampleOffset = -delta + This->mInToOutSampleOffset;
Everything now works as it should
Rolf
> Message: 4
> Date: Fri, 12 Nov 2004 11:58:17 -0800
> From: Jeff Moore <email@hidden>
> Subject: Re: inTimeStamp->mSampleTime in the InputProc is not reset
> To: CoreAudio API <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> There is never any guarantees about the first sample time to get passed
> to your device.
>
> The reasons for this basically boil down to the fact that the audio
> hardware and the time stamps it provides are shared amongst all the
> apps on the system. Even if your app stops all it's IOProcs, some other
> process may still be using the hardware, which keeps the same time line
> going.
>
> In addition, IOAudio-based devices have the additional behavior of
> continuing to run a little bit after being told to stop. This is done
> for performance reasons as well as to be sure that all the data that's
> supposed to be played, gets played. If the hardware is restarted during
> this time, the old timeline stays in effect.
>
> So, the behavior you are seeing is expected and common. Your code
> should not depend on any particular value in the time stamps. Instead,
> your code should pick an anchor point and measure durations relative to
> that point.
>
> On Nov 12, 2004, at 8:07 AM, Rolf Nilsson wrote:
>
> >
> > Hi,
> >
> > My recording application is partly based on the "afrecord" example in
> > the /CoreAudio/Services/AudioFileTools folder (same as TN2091)
> > and the ComplexPlayThru example.
> >
> > Everything works fine except when I tear down the whole recording
> > stuff, then start it again (without quitting the application).
> > After that the inTimeStamp->mSampleTime in the InputProc is not reset
> > but seems to have the same time values as before tearing it down.
> > If I sleep for say a second between tearing it down and starting
> > again, it's OK.
> > It seems the whole CA system needs some time to reset the device?
> >
> > Strange is I don't see this behavior in the ComplexPlayThru example.
> >
> > I tried to use AudioUnitSetProperty() with
> > kAudioOutputUnitProperty_StartTime to reset the sample times but it
> > does not work (or I'm not doing it correctly?)
> >
> > Any ideas?
> >
> > Thanks
> > Rolf Nilsson
> >
> >
> > _______________________________________________
> > 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
>
> --
>
> Jeff Moore
> Core Audio
> Apple
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: text/enriched
> Size: 2611 bytes
> Desc: not available
> Url : http://lists.apple.com/mailman/private/coreaudio-api/attachments/20041112/05914723/attachment.bin
>
> ------------------------------
>
> _______________________________________________
> Coreaudio-api mailing list
> email@hidden
> http://lists.apple.com/mailman/listinfo/coreaudio-api
>
> End of Coreaudio-api Digest, Vol 1, Issue 72
> ********************************************
_______________________________________________
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