• 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: in & out Callbacks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: in & out Callbacks


  • Subject: Re: in & out Callbacks
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 14 Feb 2005 12:00:26 -0800

Have you looked for the cause of your glitching? If you haven't pinned it down precisely, you probably should because 9 times out of 10 it's not what you think it is, especially if you are trying to synchronize multiple threads.

That said, I'm a bit puzzled by what you are trying to accomplish. It sounds to me like you are trying to take input received from one device, process it, and put it out on another device, which necessitates synchronizing the two IO threads. Yes?

First off, I'd look very closely at how you are synchronizing the threads. If there are mutexes involved, I'd check them thoroughly to be sure that the IO thread can never, ever block on them. Otherwise, you will glitch.

Next, as you surmise, you can't directly control the phasing of the two IO threads with AudioDeviceStart(). You need to use AudioDeviceStartAtTime() to do that. This allows you to set things up so that the input device's IO thread runs out of phase with the output device's IO thread by making them start at particular times using IO buffer sizes that represent the same amount of time. This allows you to be sure that the input is delivered before the output.

The only problem you'll have with that scheme is drift over time if the input device is not synchronized with the output device in hardware. The drift will slowly shift the phase between the input and output threads until they eventually coincide. The speed at which this happens depends on the rate scalar between the devices. The only way to fix it would be to periodically stop and restart things.

On Feb 12, 2005, at 9:53 AM, Lubor Prikryl wrote:

Hi,
My app is processing a stack of effects. I did the following:
- in the input callback I copied data from mBuffers[].mData to my buffers
- in the output callback I processed the data and copied them back to mBuffers[].mData
On certain systems generally with higher CPU load (but NOT overload) my application clicks and pops from time to time.
To fix it, I changed to this:
- in the input callback I do nothing
- all the work was done in the output callback
My questions:
- What is better? (I think the second, but it cannot be used generally)
- For the first approach, is it guaranteed that callbacks are called exactly i-o-i-o-i-o-i-o-i-o-i-o... for one device? (I perform checking, it actually seems to be regular)
- The second approach can't be used with USB class driver or with two externally synced devices unless I would establish circular buffers and increase latency. I expect some non-regular alternating here, correct?
- If I would replace the AudioDeviceAddIOProc based HAL i/o by an AudioUnit i/o, I would get to the bad situation with the usb class compliant driver and externally synchronized devices, I would open two AUs to handle, but only one i/o AU is allowed per one Graph.
Thanks for a hint
Lubor


--

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
  • Follow-Ups:
    • Re: in & out Callbacks
      • From: Lubor Prikryl <email@hidden>
References: 
 >in & out Callbacks (From: Lubor Prikryl <email@hidden>)

  • Prev by Date: Re: AudioUnit issues with GarageBand
  • Next by Date: AU parameter display flags
  • Previous by thread: in & out Callbacks
  • Next by thread: Re: in & out Callbacks
  • Index(es):
    • Date
    • Thread