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: "David A. Hoatson" <email@hidden>
- Date: Mon, 31 Jan 2005 13:55:32 -0800
- Organization: Lynx Studio Technology, Inc.
Jeff,
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.
Of course, I understand that. I was just making a generalization. Sorry
that I wasn't clear enough about that.
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.
I obviously didn't explain my situation clear enough. I already understand
that 'other' audio cards work OK in the normal sense. Ours does too - when
used with internal clocking. Our hardware is unique in that it has
frequency counters on every input that can be a clock source. This means
our driver actually looks at the frequency of the clock and the requested
rate from the application (Core Audio) and determines if the combination is
OK. If there is a frequency mismatch, the driver calls
'hardwareSampleRateChanged()'. It also polls the frequency counter looking
for external changes in the clock and calls 'hardwareSampleRateChanged()'
when it notices a change. I used to call setSampleRate until I looked at
the darwin source for that call and determined that it doesn't request a
device restart. I started calling hardwareSampleRateChanged() so it will
restart the audio devices once a sample rate change is detected.
The example USB driver doesn't really help in this situation, as that USB
driver doesn't support external clocking (as far as I can tell). It only
ever calls setSampleRate() on initHardware, and doesn't even have a control
'kIOAudioSelectorControlSubTypeClockSource'.
So, our hardware can be clocked externally (say, from an external A>D
converter). When the user presses a button on that external device that
changes the sample rate, we detect that new sample rate and call
hardwareSampleRateChanged(). My assumption was that the application could
pick up that change. So far, no OSX applications that we have tested do
this. Is there some other call that I should be making from a driver point
of view that application (CA HAL) would notice the change in sample rate?
The second problem is the application trying to set a sample rate when
external clocking is active. In this case the driver knows better than the
application (I know, I know, Core Audio HAL), what sample rate is valid/to
be used. At the moment, I override the sample rate sent to
performFormatChange. Do you think it would be better to just fail the call
when there is a sample rate mismatch?
Hopefully I have explained the situation better... :-)
Thank you,
David A. Hoatson
Lynx Studio Technology, Inc.
www.lynxstudio.com
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
_______________________________________________
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