• 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
Known issues with VST-AU based AudioUnits
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Known issues with VST-AU based AudioUnits


  • Subject: Known issues with VST-AU based AudioUnits
  • From: Bill Stewart <email@hidden>
  • Date: Fri, 20 Jun 2003 16:35:40 -0700

There are a number of audio units that are exhibiting some bad behaviours that are based on this SDK... If this is something you have used to port a VST plugin to an AU we would like these issues to be fixed by those audio units.

(1) StreamFormats are incorrectly reported for lpcm
The AU uses the much discussed AudioStreamBasicDescription to describe the formats that it has and to receive those formats for its inputs and outputs...

The ASBD from this SDK is invalid and thus causes problems with clients using this as it is meant to be used - (whether that is callbacks or connections to other units)... Unfortunately there is no easy workaround for this and this must be fixed by the Audio Units that are using this.

The classes in the SDK in PublicUtility (notably CAStreamBasicDescription)- which are also used in the CoreAudio SDK's AUPublic classes for AudioUnit development - describe in code how this structure should be filled out... If you have any questions about this please ask or look through the list archives...

We'll be covering this and how CoreAudio generally deals with formats in our sessions at WWDC this year in some detail.

(2) AU properties calls crash if AU is not initialized.
The state of an AU is basically handled through properties... We always intended that AU's should at least be able to report their property values (ie. GetProperty) without requiring initialization - basically a typical scenario would be:
Open AU
Set AU's State with the Get/Set property calls
Initialize the AU
Render with it....

If an AU cannot respond to a property when it is un-initialized, that it would return the kAudioUnitErr_Uninitialized - that then signifies to the host that the AU needs to be initialized...

Unfortunately, we're seeing many 3rd party AU's that will crash when asked questions before being initialized... Initialization was always expected to be the call where an AU can spend as much time as it needs to do its work to be ready to render - thus we generally expect this call to "take some time" This has placed a burden on hosting apps - and thus an unwelcome waste of time for users of apps - to initialize audio units before anything is done with them... (which is the lesser of two evils as at least it doesn't crash!)

If you have any questions about these issues, or any other AU issues, or even just want to show us how your AU works - then we'll be in the lab from 1-6PM on Wednesday next week at WWDC

Thanks

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.
  • Follow-Ups:
    • Re: Room for the Lab?
      • From: Robert Grant <email@hidden>
  • Prev by Date: Re: How to detect Audio device add and remove
  • Next by Date: Re: MusicDevice instrumentIDs and presets
  • Previous by thread: Re: AudioDeviceRead and timestamps
  • Next by thread: Re: Room for the Lab?
  • Index(es):
    • Date
    • Thread