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

Application Support of hardwareSampleRateChanged and external clocking


  • Subject: Application Support of hardwareSampleRateChanged and external clocking
  • From: "David A. Hoatson" <email@hidden>
  • Date: Mon, 31 Jan 2005 08:44:29 -0800
  • Organization: Lynx Studio Technology, Inc.

Hello,

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.

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


  • Follow-Ups:
    • Re: Application Support of hardwareSampleRateChanged and external clocking
      • From: Jeff Moore <email@hidden>
  • Prev by Date: Ogg QT Component not decompressing
  • Next by Date: Experience with QTMA?
  • Previous by thread: Ogg QT Component not decompressing
  • Next by thread: Re: Application Support of hardwareSampleRateChanged and external clocking
  • Index(es):
    • Date
    • Thread