• 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: HAL user-land audio driver
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HAL user-land audio driver


  • Subject: Re: HAL user-land audio driver
  • From: Jeff Moore <email@hidden>
  • Date: Wed, 26 Mar 2008 11:39:13 -0700


On Mar 26, 2008, at 5:25 AM, Mikael Hakman wrote:
Before I ask my question, I need to describe how I understand certain things, please correct me if I'm wrong.

When 2 applications simultaneously access my plug-in, HAL will create 2 instances of it with each instance executing in a corresponding application's process space.

This is correct.

As long as my plug-in is only an interface to some other shared resource, this will work without problems.

This is correct.

If my plug-in holds some state information or implements some property using its static or heap data area memory then a new instance of this area will be contained within each process.

This is correct.

When an application calls e.g. a property set method then this call will arrive only to plug-in instance owned by that application, but not to the other plug-in instance.

This is correct.

If actual property setting (state) is implemented on applications heap or static data area then this property will be set only in that particular instance.

This is correct.

How do I synchronize property settings among the 2 instances?

I prefer to use Mach messaging (using MIG) for my IPC needs, but you can use whatever mechanism you like best.


Are the basic (and laborious) shared memory and/or IPC and/or dividing the plug-in into multiple clients/shared server architecture the only alternatives?

You are definitely going to be using shared memory and/or IPC, but whether you use a client/server or peer-to-peer styled protocol depends totally on what you are trying to accomplish.


Furthermore, if the actual effect of a property setting is implemented in my plug-in code, not in some shared code farther down the chain, then this setting will have an effect in one instance but not in the other. For example, if I implement mute control in my plug-in by replacing contents of audio buffers passed from application by silence then the audio will be muted only in plug-in instance owned by the application that muted it. The other application will still produce audible output.

This ultimately depends on how your plug-in works, but is basically accurate.


Could you please comment on this issue?

About the only thing I have to add is that this is among the reasons why writing a user-land driver is difficult. As soon as your plug-in instances need to share state, your task becomes that much more tricky.


--

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: HAL user-land audio driver
      • From: "Mikael Hakman" <email@hidden>
References: 
 >HAL user-land audio driver (From: "Mikael Hakman" <email@hidden>)
 >Re: HAL user-land audio driver (From: "Mikael Hakman" <email@hidden>)

  • Prev by Date: Re: AudioQueue and Seeking in a VBR file
  • Next by Date: Re: I can't get breakpoints to work?
  • Previous by thread: Re: HAL user-land audio driver
  • Next by thread: Re: HAL user-land audio driver
  • Index(es):
    • Date
    • Thread