• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Avoiding delay on starting sound
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoiding delay on starting sound


  • Subject: Re: Avoiding delay on starting sound
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 24 Jan 2005 12:22:53 -0800

There are no guarantees about the amount of time between starting your IOProc (AudioOutputUnitStart is implicitly starting the IOProc of an instance of AUHAL) and the first time it gets called. The reason why is that that IO thread has to be created, bootstrapped and started running. Not to mention the fact that the hardware itself usually needs to be started, which can take an unbounded amount of time (e.g. powering up the sleeping built-in sound chip on a portable).

Consequently, the best way to do what you want to do is to always run your IOProc and output 0's until you are ready to output real data. You can have sample accurate positioning that way.

On Jan 24, 2005, at 2:55 AM, FILIPPIN LUCA wrote:

Hi,
sorry if this issue was already submitted to your attention, but I was
not able to find it in the mailing list archive.
I wrote some simple code to play an audio file using my AudioRenderCallBack.
Between the AudioOutputUnitStart call and the call of my render callback
function I misure a delay of few ms (from 2to 5ms). It seems that this delay
depends on the buffer frame size (that can be set by
kAudioDevicePropertyBufferFrameSizeRange property): the lesser this size is,
the lesser will be the delay (but also, more often the render function will
be called, possible resulting in CPU overload and clicked sounds ). If I've
well understood, this buffer frame size determines the frequency at which
*sincronously* all the render funcion are called. My question: is there a
way to get that AudioOutputUnitStart trigger immediatly (and asincronously
respect to normal behaviour) my render callback, without introducing any
delay? Someone told me that starting early the audio unit and feeding it
with zero's till the moment I want start my proper sound will overcome the
problem, but what does this means exacly I can't understand, as I know that
the render function calls comes *sincronously* anyway, with frequency which
depend on the buffer frame size of the audio device. I need to make the
delay closest as possible to zero


--

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
References: 
 >Avoiding delay on starting sound (From: FILIPPIN LUCA <email@hidden>)

  • Prev by Date: midi with midieffectbase
  • Next by Date: Re: AirTunes API and DTS
  • Previous by thread: Avoiding delay on starting sound
  • Next by thread: midi with midieffectbase
  • Index(es):
    • Date
    • Thread