Re: Application Support of hardwareSampleRateChanged and external clocking
Re: Application Support of hardwareSampleRateChanged and external clocking
- Subject: Re: Application Support of hardwareSampleRateChanged and external clocking
- From: Jeff Moore <email@hidden>
- Date: Mon, 31 Jan 2005 12:25:11 -0800
Your driver doesn't actually inform an application of anything
directly. The API calls you make are contained wholly within the
driver/IOAudio family. They get across the user/kernel boundary via the
IORegistry and other IOKit mechanisms where the HAL fields them,
figures out what to do with them, and what it's clients need to know
about the change. Only then do the clients of the HAL get notified that
something changed.
That said, other pieces of hardware don't seem to have issues with
changing the sample rate and getting the right thing to happen in
user-space. Indeed, I see it happen everyday. So, it sounds to me like
there are some order of operations problems in the driver that is
confusing things out in user-space. I heartily recommend taking a look
at the USB Audio driver or the built-in driver to see how they handle
informing user-space of sample rate changes. Most likely, your driver
is skipping a step or two.
On Jan 31, 2005, at 8:44 AM, David A. Hoatson wrote:
Our Core Audio driver calls hardwareSampleRateChanged() when it
detects a sample rate change from an external device (when clocking
externally).
From our in-house testing application support for using this call is,
at
best, limited. Some applications seem to notice that we called
hardwareSampleRateChanged (Nuendo, Cubase), but then don't do anything
useful with the information. Some applications (DP4 and Logic 7),
will simply hang when the external sample clock is changed, and it is
'Force Quit' time. Obviously this is a serious problem for the end
user as they are used to pressing the sample rate button on their
external converter...
Is there any other way to notify the application that the external
clock has changed, so it can do something useful with this information
(such as inform the user!)? Nuendo/Cubase with our Windows ASIO
driver handle the sampleRateDidChange() callback very nicely by
popping up a dialog box telling the user that the sample rate changed
and what the new rate is. So far, no OSX applications that we have
tested do this.
I should also say that our Core Audio driver does look at the sample
rate of the external clock and will change the requested rate
(performFormatChange) to the rate of the external clock (and call
hardwareSampleRateChanged from within the performFormatChange
handler). We have noticed that sometimes this will cause the
application to get caught in an endless loop (when the app thinks it
really has control over the sample rate, and it doesn't).
Any ideas as to how to make this work more smoothly?
I would specifically like to hear from application developers as to
what they are expecting the hardware driver to do with respect to
external clocking.
--
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