Re: running state of driver
Re: running state of driver
- Subject: Re: running state of driver
- From: Jeff Moore <email@hidden>
- Date: Thu, 7 Aug 2003 18:07:50 -0700
If IO was being done with the driver by the HAL, it would be the HAL
that would restart things when it receives the notification from the
driver. It's pretty much the same sort of thing that happens when a
stream's format changes.
One thing that causes some issues is that the notifications reach the
HAL in various process asynchronously. In the mean time there could be
lots of calls to performClientIO happening, even after you've paused
the device in the driver. This usually causes a few overloads to take
place before the HAL processes any of the notifications. Some apps,
like Logic, will stop things on their own when this happens.
What apps are having issues?
On Thursday, August 7, 2003, at 5:20 PM, Robert Penland wrote:
In my audio driver code, when I receive a input selector change call I
perform the following operations:
pauseAudioEngine();
beginConfigurationChange();
...
(change my hardware)
...
completeConfigurationChange();
resumeAudioEngine()
What I am noticing in some applications is that if my driver was in a
running state before the inputSelectorChange call is made is that it
doesn't return to the running state after the call. In the
IOAudioFamily code I see that the resumeAudioEngine() call just puts
the audio driver into the kIOAudioEngineResume state and sends a
kIOAudioEngineResumedNotification notification. Is it up to the
application to respond to the kIOAudioEngineResumeNotification and get
the engine running again?
Thanks,
Rob
--
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.