Re: Coreaudio-api Digest, Vol 3, Issue 254
Re: Coreaudio-api Digest, Vol 3, Issue 254
- Subject: Re: Coreaudio-api Digest, Vol 3, Issue 254
- From: "Nick Hebner" <email@hidden>
- Date: Wed, 16 Aug 2006 16:38:36 -0700
On 8/16/06, Nick Hebner <email@hidden> wrote:
> I am new to the core audio api and mac programming in general. I am
> looking at writing an application
> for which I need to have access to all audio streams on the system.
> My initial idea was to write it using
> core audio api's to enumerate all streams on all devices, and fiddle
> with these streams.
OK. I'm with you so far. I'll just point out that in /Developer/
Examples/CoreAudio/HAL/HALLab, you'll find a project that builds an
app that puts a GUI on all the HAL's properties. Makes for an easy way
to explore the hardware.
> I wrote a test
> program to see if this would work, it was indicating that there was
> only one stream on my one output device,
> even when I was playing audio with iTunes and GarageBand.
This is correct. You are enumerating the output streams of the
hardware and for our built-in hardware, there is only one.
Ok, I am a little confused by this, please let me know if my understanding of the system is correct. From viewing the IORegistry entry for my audio device in IORegistryExplorer, I noticed that a seperate IOAudioEngineUserClient is created and destroyed in my
audio device each time I open and close an audio application, meaning that these are per-application objects, correct? I thought that each application should only have one of these, but may have multiple IOAudioStreams within an IOAudioEngine.
oops, didnt finish my thought, sorry...
Is it the driver that determines how many streams are allowed? I dont understand this.
> Am I able to access streams from other applications
The short answer is no. There are no APIs for directly accessing the
audio data coming out of other processes.
The long answer involves writing a fake device using the HAL's user-
land driver plug-in API or some kind of in-kernel reflector.
Using the device plugin approach, would I need a seperate plugin for each different device, or would a generic one work for all audio devices? Is there some in depth documentation or examples on driver plugins somewhere?
> , and if so how?
You can also just use something like Jack, which uses the user-land
approach. SoundFlower or the lowly AudioReflectorDriver in our SDK do
the job of being a fake device by being an in-kernel reflector.
My aim is slightly different from these in that, I do not want to redirect the audio back to an application, I just want to have access to all AudioEngines in the system, so a device plugin would probably be the best approach for this right?
> Are these programs using other audio frameworks such as quicktime,
> etc?
No. They are all using Core Audio in one fashion or another.
> How do all of these frameworks access the same audio hardware, do
> they use core audio at their heart, or is
> it something else?
Audio device sharing is just how things have always worked on the Mac,
even before X came about.
--
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