• 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: DeviceIsRunning for which IOProc?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DeviceIsRunning for which IOProc?


  • Subject: Re: DeviceIsRunning for which IOProc?
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 7 Jul 2003 12:21:16 -0700

On Sunday, July 6, 2003, at 4:24 PM, Brian Willoughby wrote:

Hello,

I have a question regarding kAudioDevicePropertyDeviceIsRunning.

First of all, I should confirm that it is perfectly valid to call
AudioDeviceAddIOProc() more than once to register different callbacks in the
same process. I sure hope so, because this seems to be working as far as
providing two different audio data streams.

It is legal but discouraged for performance reasons. Each IOProc has to have it's own set of buffers which uses up precious physical RAM. Further, using the driver to do the mixing is less efficient than doing it in the application due to the locks involved in the kernel.

So, you can do it, but you really shouldn't. If you want two streams, just install one IOProc and do the mixing yourself when your IOProc is called. You can use the mixer Audio Unit connected to the HAL output Audio Unit.

What I have found is that I need to track kAudioDevicePropertyDeviceIsRunning
to keep in sync with whether it is safe to Stop or Start my deviceIOProc. But
my problem is that I cannot distinguish which IOProc is starting or stopping
when the notification arrives in my listener.

In other words, AudioDeviceStart() and AudioDeviceStop() each take an
AudioDeviceIOProc parameter to specify which IOProc should be affected.
However, the resulting property listener notification has no such
distinguishing parameter, either when adding the listener, or when the property
change notification arrives. ... at least, not unless I've missed something.

Any ideas?

I don't think I can just ignore the DeviceIsRunning notifications, because my
own attempts to track start/stop state in a local flag are not perfectly
accurate when the user is punching in and out at a highly frequent rate. But I
cannot figure out how to use the notifications as they are.

The reason why is that there is only one IO thread per process per device. All registered IOProcs for a device in a given process are called in series from the same IO thread at the same point in the cycle. Hence, kAudioDevicePropertyDeviceIsRunning applies to the IO thread in the process for the device, not to any individual IOProc.

IMHO, you shouldn't be using the HAL directly for you app. Everything you've posted makes me believe that you'd be much better served using the appropriate Audio Units. It would result in an app that is friendlier to the rest of the system and one that performs better.

--

Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: RE: Sound Input Manager under OSX
  • Next by Date: Re: Audiofile buffering
  • Previous by thread: Re: Sound Input Manager under OSX
  • Next by thread: Can I delete a coreMIDI client with open ports OK?
  • Index(es):
    • Date
    • Thread