• 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: Application Support of hardwareSampleRateChanged and externalclocking
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Application Support of hardwareSampleRateChanged and external clocking (From: "David A. Hoatson" <email@hidden>)
 >Re: Application Support of hardwareSampleRateChanged and external clocking (From: Jeff Moore <email@hidden>)
 >Re: Application Support of hardwareSampleRateChanged and external clocking (From: "David A. Hoatson" <email@hidden>)
 >Re: Application Support of hardwareSampleRateChanged and external clocking (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: OS X USB/Midi Driver bugs?
  • Next by Date: Re: Application Support of hardwareSampleRateChanged and externalclocking
  • Previous by thread: Re: Application Support of hardwareSampleRateChanged and external clocking
  • Next by thread: Re: Application Support of hardwareSampleRateChanged and externalclocking
  • Index(es):
    • Date
    • Thread