Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
- Subject: Re: Programmatic Aggregate Device issue on Intel Mac, not always completing initialisation?
- From: Jeff Moore <email@hidden>
- Date: Mon, 07 Jul 2008 15:32:12 -0700
So you don't say how what devices you are trying to aggregate. It
would be helpful to know precisely what we are talking about here.
At any rate, I have a few questions:
- You say that this only happens on Intel hardware, is that because
you've tested your aggregation code on PPC and found it working fine
or that you only are doing aggregation on Intel hardware because the
PPC hardware is already generally full-duplex?
- What is the sample rate of the various sub-devices in the
aggregation and which sub-device has been designated the master?
- Is the aggregate device you are creating private?
- You say that it works fine in the case where you are using two
separate processes, but you get the problem when you are using a
single process. Can you elaborate on what the differences are between
the environments?
- Are you carefully checking for errors from each and every API call?
Are you seeing any?
- Can you walk through how you are creating the aggregate device? The
honest truth is that I don't have time to wade through your code and
debug your problems for you so it is always much more helpful if you
can boil down your code into snippets that you can post.
Finally, as you say there have been issues in the past with
programmatically created aggregate devices. The usual way this has
manifested is that a newly created aggregate device will seem to
disappear for a moment after it is created. The way I've seen folks
work around this issue is to do add some code to pause after creating
the aggregate and then to look up the aggregate's AudioObjectID again
using kAudioHardwarePropertyDeviceForUID. It's not a cure all by any
means but it has helped a few developers.
At any rate, here's what the pseudo-code would look like:
// create the aggregate device
<... make a bunch of HAL calls ending with a new aggregate device
getting created ...>
// task the thread's run loop for 100 milliseconds to make sure that
things got done
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false);
// use the UID of the aggregate device to look up it's AudioObjectID
<... make a call to AudioObjectGetPropertyData on the system object
using kAudioHardwarePropertyDeviceForUID ...>
On Jul 3, 2008, at 7:42 AM, Dan wrote:
We're trying to add automatic creation of an Aggregate Device to an
open-source audio software called SuperCollider. The audio engine has
two ways of running: either as a separate process, or launched within
the main application process.
Now, we have a patch for the Aggregate Device issue, and it works fine
in the first case (audio engine is separate). But in the second case
(audio engine "internal" to application) there seems to be a problem
on Intel Macs, where the IOProc callback for the audio device is never
called. It's the same code being called in each case, so maybe
something subtle is going on.
If using a "real" device, or a user-created aggregate, there is no
problem starting the audio callback.
I've seen in the archives of this list discussion of the occasional
bug in the programmatic interaction with Aggregate Device creation
etc. If you can suggest whether this is a bug or our own fault that
would be extremely helpful!
--
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