• 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: Some more questions about sample rate notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some more questions about sample rate notifications


  • Subject: Re: Some more questions about sample rate notifications
  • From: Jeff Moore <email@hidden>
  • Date: Tue, 15 Jan 2008 10:07:31 -0800


On Jan 15, 2008, at 9:23 AM, Stéphane Letz wrote:

>kAudioDevicePropertyDeviceIsRunning is only ever sent from the devices IO thread. It gets sent when the IO thread finishes initializing itself to indicate that things are running as well as when the >thread is exiting to indicate that things have stopped. There are no other ways to get this notification (BTW, you can see this for yourself in the HAL plug-in SDK in the class HP_IOThread). If you are >indeed seeing this notification, it means that somebody is starting IO in your process. If it isn't you, then it is some API you depend on like QT or something else.

No use if QT at all.. but of AUHAL yes. Could it be the reason?

Doubtful, although AUHAL will restart IO if was running when the change happened. The IsRunning notification is probably the most predictable notification the HAL puts out given the limited circumstances it can be sent under.


I'd set a breakpoint on AudioDeviceStart() to see who was calling it. FYI, I was helping out another developer a couple of months ago with a similar issue of the hardware starting seemingly mysteriously. Despite this developer promising me that their app's engine wasn't the one starting the hardware, it turned out that there was an edge case in their code that was indeed starting IO when the app wasn't really ready and causing all their problems.

The take away here is that until you fully debug it, I'd not assume anything about this case.

That said this does not help a lot for the initial question. What would be the best property to listen to to detect a change in the aggregate driver?

It would depend on what state you were interested in keeping track of. Aggregate devices support the full panoply of notifications.


is there a way to know when sub-device of the aggregate are dropped? or the stream layering maybe?

kAudioAggregateDevicePropertyActiveSubDeviceList tracks the active subdevices in an aggregate (as opposed to kAudioAggregateDevicePropertyComposition which tracks the full make up of the aggregate).


But the more general kAudioDevicePropertyStreamConfiguration would be better to use as it will catch this case for non-aggregate devices too.

--

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: 
 >Re: Some more questions about sample rate notifications (From: Stéphane Letz <email@hidden>)

  • Prev by Date: Re: Some more questions about sample rate notifications
  • Next by Date: Re: linear PCM
  • Previous by thread: Re: Some more questions about sample rate notifications
  • Next by thread: Virtual Audio Device
  • Index(es):
    • Date
    • Thread