Re: Application Support of hardwareSampleRateChanged and externalclocking
Re: Application Support of hardwareSampleRateChanged and externalclocking
- Subject: Re: Application Support of hardwareSampleRateChanged and externalclocking
- From: "David A. Hoatson" <email@hidden>
- Date: Mon, 31 Jan 2005 17:39:21 -0800
- Organization: Lynx Studio Technology, Inc.
Hello,
So, our hardware can be clocked externally
I would argue that the source of the sample rate change doesn't matter to
user-land entities. All that matters is that the sample rate changed.
It's all the same from this perspective, so it doesn't really matter that
your hardware is externally clocked. A sample rate change is a sample
rate change.
I'm not sure I agree, but I'll deal with that later. :-)
The problems you are describing are exactly the sorts of things I have
seen happen when a driver isn't changing the format correctly within the
context of the IOAudio family. From the sound of it, you've been
experimenting with what APIs to call. IMHO, you should be doing the
_exact_ same thing you would do if the request to change the hardware
came from the HAL (save for the actual hardware changes since presumably
that's already taken place). The exact same sequence of notifications
needs to be sent, at any rate.
I am doing exactly the same thing. In both instances I call
hardwareSampleRateChanged. All of the example code called setSampleRate,
but as I said before, once I looked through the Darwin source for that call
it was obvious it wasn't doing what we needed.
If the driver can't accept a given format under a particular set of
circumstances, it needs to do two things. First, it should never offer an
illegal format as available. This means you have to update your format
lists to be accurate for the circumstances and send the appropriate
notifications to the HAL when they change.
OK. It never occurred to me that I would have to rebuild the
AvailableFormats when the device was clocking externally. I can certainly
do that (although I have never seen any of the sample code do that, but
then I've only looked at about 3 different examples, none of which can
clock externally!).
I still don't see how rebuilding the AvailableFormats list is going to help
the instance where the sample rate changes externally and the application
is already running. I guess I'll have to poke through the Darwin source
for addAvailableFormat to see how the notification works.
Second, the driver should return an error if an illegal format is
selected. The driver should definitely not pretend that the format is
legal and then do nothing.
This actually raises and additional question. I have two 'sets' of formats
in the AvailableFormats list. One set is just an entry for specific sample
rates (min & max are the same), and the last entry is the range of sample
rates our PLL actually supports (min is 8000 & max is 215000). When
clocking externally, I assume you are saying that there should only be one
entry in the list, where min & max are the same - and they are the rate of
the external clock. Once I notice the clock has changed rates, I
clearAvailableFormats() then rebuild the list with only one entry.
Thanks for your help on this Jeff. I really appreciate you taking the time
to walk me through this.
Thank you,
David A. Hoatson
Lynx Studio Technology, Inc.
www.lynxstudio.com
_______________________________________________
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