• 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
Revised CF Types and AU (fixed I think)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Revised CF Types and AU (fixed I think)

  • Subject: Revised CF Types and AU (fixed I think)
  • From: Bill Stewart <email@hidden>
  • Date: Tue, 5 Aug 2003 02:21:53 -0700
OK - I wasn't thinking - and there is a clean resolution to all of this with one change:

Here's the current list:
Set
Caller CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_CurrentPreset
kAudioUnitProperty_ElementName

kMusicDeviceProperty_SoundBankData
This provides data for the music device (as a void*)
Caller responsible for maintaining data pointer whilst bank-data is in use

Get
Caller must CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_ParameterValueStrings
kAudioUnitProperty_FactoryPresets
kAudioUnitProperty_ParameterValueName
kMusicDeviceProperty_BankName
kAudioUnitProperty_ParameterIDName
kAudioUnitProperty_ParameterClumpName

Caller *doesn't* CFRelease
kAudioUnitProperty_CurrentPreset
kAudioUnitProperty_ElementName
kAudioUnitProperty_CocoaUI
kAudioUnitOfflineProperty_PreflightName


Qualitified CFRelease
kAudioUnitProperty_ParameterInfo's CFName iff kAudioUnitParameterFlag_CFNameRelease is set in ParameterInfo


Part of the stupidity I just exhibited is not realising that the main confusion here are the calls to get CF property values where the client is borrowing a reference that is owned by the AU. BUT, of these 4 only one is an existing property, and the rest are new properties for Panther.

So, these can be changed and will be. (I'm gong to leave out the SoundBankData as it doesn't really apply as its not a CF property, and is probably only an unique property to the DLS synth anyway)

Set
Caller must CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_CurrentPreset
kAudioUnitProperty_ElementName

Get
Caller must CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_ParameterValueStrings
kAudioUnitProperty_FactoryPresets
kAudioUnitProperty_ParameterValueName
kMusicDeviceProperty_BankName
kAudioUnitProperty_ParameterIDName
kAudioUnitProperty_ParameterClumpName
kAudioUnitProperty_ElementName
kAudioUnitProperty_CocoaUI
kAudioUnitOfflineProperty_PreflightName

Caller *doesn't* CFRelease
kAudioUnitProperty_CurrentPreset


Qualitified CFRelease
kAudioUnitProperty_ParameterInfo's CFName iff kAudioUnitParameterFlag_CFNameRelease is set in ParameterInfo

The one property that has a vagueness about it is CurrentPreset (I'll come back to the parameter names) - this is the change that is required.

So, I would propose that we deprecate this property and replace it (essentially alias it) to:
kAudioUnitProperty_PresentPreset

(The property would return the same as the current preset property, just doing a CFRetain on the preset name before returning it)

So - the list would look like this:

Set
Caller must CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_PresentPreset
kAudioUnitProperty_ElementName

Get
Caller must CFRelease
kAudioUnitProperty_ClassInfo
kAudioUnitProperty_ParameterValueStrings
kAudioUnitProperty_FactoryPresets
kAudioUnitProperty_ParameterValueName
kMusicDeviceProperty_BankName
kAudioUnitProperty_ParameterIDName
kAudioUnitProperty_ParameterClumpName
kAudioUnitProperty_ElementName
kAudioUnitProperty_CocoaUI
kAudioUnitOfflineProperty_PreflightName
kAudioUnitProperty_PresentPreset

Qualitified CFRelease
kAudioUnitProperty_ParameterInfo's CFName iff kAudioUnitParameterFlag_CFNameRelease is set in ParameterInfo

In other words whenever a client deals with a CF Object it owns its reference to it ... No ambiguity now.

Now, what about the parameter names?

As described previously, we've introduced a new parameter flag:
kAudioUnitParameterFlag_CFNameRelease

How does a host deal with this?

Its actually pretty simple - it required one additional line in the generic view to support this flag properly (and that code will be in the Panther SDK, as the view code is already of course)
GetParamInfo (mParam)
if (!(mParam.mFlags & kAudioUnitParameterFlag_CFNameRelease))
CFRetain (mParam.cfParamName)

Then when mParam is throw away you always release the cf param name, as you take a retain count on it when the parameter name does NOT have this retain flag set...

How does the AU deal with this?

Some parameters names (most in fact) can be generated statically, and for localisation these can be generated once (as our latest SDK release actually does).

To change the parameter reporting mechanism is *not* an option... (Apps can't go releasing parameter names without the potential to crash currently, and there is a good possibility that these are leaking in some cases).

In some cases, a parameter name maybe generated programatically (for instance our new Multiband compressor generates read only parameters on initialization to describe the amount of compression that is being applied across its 4 bands on each of the I/O channels (except stereo, where it runs in a stereo linked mode).

There is a helper method in AUBase to take a CFString - AUBase::FillInParameterName that took the param Info struct and a CFStringRef.

As we introduced this release flag ourselves, I decided to change the signature of this method to also take a boolean that describes if the CFString requires releasing or not... (So, this will break ALL AU code that uses this that recompiles, as it now requires an extra boolean and this ISN'T shipped with default argument value).... OK - so you all would then know you have to deal with this

(and if your objects are always generating (or not) - as long as its always consistent) you can give this 3rd arg a default value, and your code will recompile just fine :)


So, I think that is reasonable and far less ugly than my earlier post.

Bill

-- mailto:email@hidden
tel: +1 408 974 4056

________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
References: 
 >CF Types and AU (From: Bill Stewart <email@hidden>)

  • Prev by Date: Re: CF Types and AU
  • Next by Date: Re: CF Types and AU
  • Previous by thread: CF Types and AU
  • Next by thread: Re: CF Types and AU
  • Index(es):
    • Date
    • Thread