• 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: setClockDomain usage
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setClockDomain usage


  • Subject: Re: setClockDomain usage
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 23 Mar 2009 11:23:43 -0700


On Mar 22, 2009, at 9:27 PM, email@hidden wrote:

I'm writing a kext driver for a USB 2.0 audio device, starting with the Apple USB audio reference code from 10.5.6.

The device's output engine is synced to the input engine, and there is not feedback endpoint, so the setClockDomain function seems ideal to use.

The clock domain property is there to advise the user-space world about which IOAudioEngines are synchronized in hardware. It is an integer value such that if two engines have the same value, then the two engines are synchronized in hardware.



The alternative is to start up two streams in a single engine, but that requires separating a lot of the vars into input and output sections. Doable, but just a lot of work now, when setClockDomain seems less troublesome.

After digging around, I found kIOAudioEngineClockDomainKey to get the clockDomain for the input engine. The clockDomain turns out to be the address of the ioAudioEngine object. So I call the output engine's setClockDomain with the input clockDomain.

The catch here is that the clock domain property doesn't do anything other than convey a piece of information to user-space. Other than that, it has no material impact on IO from the driver's perspective. So doing this, while nice and informative, doesn't solve any problems related to synchronizing the two halves of your device.



For output only operation, the input engine needs to be running. It appears that the input engine is not automatically started. So I am proposing to start the input engine with performAudioEngineStart at the beginning of the output engine's performAudioEngineStart.

If I call performAudioEngineStart, will this cause a problem with multiple performAudioEngineStarts? Do I need to keep a reference count of starts, and ignore the stops till the count returns to zero?

Do I need to skip all timestamp actions in the output engine, or will the engine ignore them?

Your thoughts on these questions or the overall architecture are much appreciated.

If the input and the output are truly synchronized and interdependent, as you say, they really have to be represented as a single IOAudioEngine.


--

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
References: 
 >setClockDomain usage (From: email@hidden)

  • Prev by Date: Re: Audio Unit Volume
  • Next by Date: Re: AudioFileReadPackets from buffer?
  • Previous by thread: setClockDomain usage
  • Next by thread: Changing the audio session audio route (Speaker or none ) when using AVAudioPlayer
  • Index(es):
    • Date
    • Thread