• 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: Sample times in input procs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sample times in input procs


  • Subject: Re: Sample times in input procs
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 7 May 2007 11:20:21 -0700



On May 5, 2007, at 8:32 PM, Neil Clayton wrote:

I'm debugging a play thru error I've got, and I've noticed some behavior I don't understand.

I'm playing system sound to the Soundflower 2(ch) device (some of you may be familiar with this open-sourced driver from Cycling74).

I'm generally familiar with this driver.

I'm using this as my input device.
Without any audio playing (from iTunes, for example) - My playthru gets initial sample times of "29" (or, rather, very low numbers).


If I restart my app. And have sound playing through iTunes, then the first sample time I see in the input proc comes out at about 42513 (or similar).

My question is - is this valid? An input proc can receive sound with any sample time? Do I take it that the sample time provided to the input render proc is whatever time the device connected to the render proc gives out?

I'm assuming "yes", but wanted to check here.

I'm presuming you are using the HAL directly, yes? That being the case, you have to remember that the sample times the HAL gives you are _global_ to the machine as the device is global to the machine. When you get a sample time that is large as the first sample time passed to you IOProc, that usually means that the device is in also in use in some other process.


Note also that even if no other process is using the device, you can still get this behavior because IOAudio-based drivers run for a brief period of time after they have been told to stop. If another client starts in this "cooling off" period, then the time stamps continue on as if the hardware hadn't been stopped at all.

If, on the other hand, you are using AUHAL (aka the Default Output Unit), you can adjust this behavior using the property kAudioOutputUnitProperty_StartTimestampsAtZero to tell our instance of AUHAL to always start the time stamps it gives you at 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: 
 >Sample times in input procs (From: Neil Clayton <email@hidden>)

  • Prev by Date: Re: Streaming audio to built-in audio device
  • Next by Date: Re: Streaming audio to built-in audio device
  • Previous by thread: Sample times in input procs
  • Next by thread: [OT] - Music pauses at random intervalls
  • Index(es):
    • Date
    • Thread