• 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 external clocking
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 14:36:07 -0800


On Jan 31, 2005, at 1:55 PM, David A. Hoatson wrote:

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.


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.

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?

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. 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.


--

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
  • Follow-Ups:
    • Re: Application Support of hardwareSampleRateChanged and externalclocking
      • From: "David A. Hoatson" <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>)

  • Prev by Date: Re: Application Support of hardwareSampleRateChanged and external clocking
  • Next by Date: Re: Music Device and channel handshake
  • 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