• 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
AudioUnit: Open Times are too long
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AudioUnit: Open Times are too long


  • Subject: AudioUnit: Open Times are too long
  • From: Bill Stewart <email@hidden>
  • Date: Sat, 15 Mar 2003 12:46:41 -0800

I'm in the process of writing a command line validation tool for audio units.

One of the behaviours that I'm observing in many of the audio units that I have from other companies is that they are taking too long to respond to the OpenAComponent call (this calls the AUBase derived constructor of your AudioUnit)

Why is this a problem?

Host apps will typically open audio units, then close them, at potentially a number of points and for a number of reasons:
For eg: To build an understanding of what channel valence properties an AudioUnit has.

Because these calls take a long time, this can substantially slow the launching of an app, particularly as more and more audio units are installed on users systems.

It was always our intention to make opening audio units a cheap operation for that reason, (this is why we have the additional state of Initialization) and our units do conform to that guideline. Most of our units will actually open under a millisecond on a G4/800 machine - and once opened can respond to queries needed for format negotiations, etc..

From a script that I wrote (that just finds all the units and times how long it takes to open them - results are printed below), there are two behaviours that I'm seeing:

The script runs the open calls in two rounds. The first round you see the overhead of loading the binaries that the AU code lives in. So, for eg, the only Apple unit that I come across is the band pass unit. First time through that takes around 50msecs to load - its the first unit - then each additional AU takes under 2 msecs (that was my cut off time - in fact most of ours load under 1 msec). The second time through, this unit's open time doesn't show, because the binary has been loaded in that process.

One unit (and I'm sorry to point fingers here - but I think EVERY 3rd party unit I've tried has problems in this area) is taking nearly a second to open the first time:
AudioUnit:0x830000
CAComponent: 0x102A0 ComponentDescription: aufx - Insp - ElAS, 0x0, 0x102A0
time to open unit = 986.344012 msecs

It disappears the second time (so consequent opening is under 2 msecs)...

This points out the second problem. I believe that one of the major reasons this unit takes so to load the first time is that it has far too many framework dependencies (for instance GUI frameworks) and is thus loading those and taking that cost the first time it is loaded.

A "first time" load time that I'd consider reasonable in this shell script program is around 50msecs - that's an unavoidable time for the code and its dependancies to be loaded. Any other Audio Units that are contained within that same bundle would NOT be hit by that time - just the first one.

We resolve this problem by building our GUI units into a separate library (If you look in the CoreAudio.component bundle you'll see a "View Components" library there. We then use a special dispatcher in the main component lib to dispatch to the view components, so that when opening our units, the binary for the actual audio units only has dependencies on frameworks needed by the AU's themselves, NOT their views. I'll have to check if that dispatcher code is in the SDK (if its not I'll add it), as we'd really like to see that loading dependency broken in ALL audio units, not just ours.

There may also be some significant static state that is being initialized the first time as well in many of these units. This is also generally frowned upon within our own development, and ANY initialization that we do is either done by the compiler:
static const int kBlah = 3

or, if dynamic (ie code needs to execute) is done lazily, on an ***as needed*** basis wherever possible (by some definition of "as needed":).

After the first round of open calls, there are still a number of units that show up with similar times to open them the second time around - funnily enough they are all from 2 companies:) This definately suggests to me that these units are either:
(1) NOT having enough static const, compile time data
(2) Doing too much work in the constructor where more of this work could either be done in AudioUnitInitialize or in response to AudioUnitProperty calls.

Why is this a problem?

Imagine I have a couple of hundred audio units installed. Imagine that the average open time of those is half a second. That means the user has to wait 10 seconds for the host (whether this is done in one hit or divided into smaller chunks) to be able to interact with their plugin environment. That does NOT seem to me a desirable user experience.

Here's the printout of my test run (if you don't see yours, then either it does do the right thing or I don't have it). I'll be making this script available in the SDK at a later date (though of course, its easy to write yourself to test this)!

* * * * * * * * doing first run of open * * * * * * * *

AudioUnit:0x810000
CAComponent: 0x102A2 ComponentDescription: aufx - Cmbo - mdaX, 0x0, 0x102A2
time to open unit = 52.961307 msecs

AudioUnit:0x820000
CAComponent: 0x102A3 ComponentDescription: aufx - Dyna - mdaX, 0x0, 0x102A3
time to open unit = 19.890257 msecs

AudioUnit:0x830000
CAComponent: 0x102A0 ComponentDescription: aufx - Insp - ElAS, 0x0, 0x102A0
time to open unit = 986.344012 msecs

AudioUnit:0x840000
CAComponent: 0x102B0 ComponentDescription: aufx - LowP - Wido, 0x0, 0x102B0
time to open unit = 52.235253 msecs

AudioUnit:0x850000
CAComponent: 0x102A5 ComponentDescription: aufx - Talk - mdaX, 0x0, 0x102A5
time to open unit = 37.798516 msecs

AudioUnit:0x860000
CAComponent: 0x102A6 ComponentDescription: aufx - Test - mdaX, 0x0, 0x102A6
time to open unit = 26.907198 msecs

AudioUnit:0x870000
CAComponent: 0x10019 ComponentDescription: aufx - bpas - appl, 0x0, 0x10019
time to open unit = 50.548098 msecs

AudioUnit:0x880000
CAComponent: 0x1029E ComponentDescription: aufx - buff - DFX!, 0x0, 0x1029E
time to open unit = 95.106425 msecs

AudioUnit:0x940000
CAComponent: 0x102A9 ComponentDescription: aufx - pola - DFX!, 0x0, 0x102A9
time to open unit = 24.625134 msecs

AudioUnit:0x950000
CAComponent: 0x102A4 ComponentDescription: aufx - rPan - mdaX, 0x0, 0x102A4
time to open unit = 33.988916 msecs

AudioUnit:0x960000
CAComponent: 0x102AC ComponentDescription: aufx - scub - DFX!, 0x0, 0x102AC
time to open unit = 100.309806 msecs

AudioUnit:0x990000
CAComponent: 0x102AD ComponentDescription: aumf - DFtv - DFX!, 0x0, 0x102AD
time to open unit = 124.540065 msecs

AudioUnit:0x9A0000
CAComponent: 0x1029F ComponentDescription: aumu - AtFr - VST , 0x0, 0x1029F
time to open unit = 586.166398 msecs

AudioUnit:0x9B0000
CAComponent: 0x102AA ComponentDescription: aumu - RzI1 - UHfX, 0x0, 0x102AA
time to open unit = 112.819751 msecs

AudioUnit:0x9C0000
CAComponent: 0x102AF ComponentDescription: aumu - VSTW - VST , 0x0, 0x102AF
time to open unit = 565.695093 msecs

AudioUnit:0x9E0000
CAComponent: 0x102A7 ComponentDescription: aumu - pmtk - 0xBA, 0x0, 0x102A7
time to open unit = 91.629654 msecs

AudioUnit:0x9F0000
CAComponent: 0x1029C ComponentDescription: aumu - synt - airy, 0x0, 0x1029C
time to open unit = 106.128918 msecs



* * * * * * * * doing second run of open * * * * * * * *

AudioUnit:0xB00000
CAComponent: 0x1029E ComponentDescription: aufx - buff - DFX!, 0x0, 0x1029E
time to open unit = 56.274350 msecs

AudioUnit:0xBE0000
CAComponent: 0x102AC ComponentDescription: aufx - scub - DFX!, 0x0, 0x102AC
time to open unit = 49.829605 msecs

AudioUnit:0xC10000
CAComponent: 0x102AD ComponentDescription: aumf - DFtv - DFX!, 0x0, 0x102AD
time to open unit = 49.443431 msecs

AudioUnit:0xC30000
CAComponent: 0x102B8 ComponentDescription: aumu - VSmp - VST , 0x0, 0x102B8
time to open unit = 11.422949 msecs

AudioUnit:0xC40000
CAComponent: 0x102B6 ComponentDescription: aumu - VSmp - VST , 0x0, 0x102B6
time to open unit = 6.272074 msecs

AudioUnit:0xC50000
CAComponent: 0x102B4 ComponentDescription: aumu - AtFr - VST , 0x0, 0x102B4
time to open unit = 102.093812 msecs

AudioUnit:0xC60000
CAComponent: 0x102B2 ComponentDescription: aumu - AtFr - VST , 0x0, 0x102B2
time to open unit = 94.112650 msecs

AudioUnit:0xC70000
CAComponent: 0x1029F ComponentDescription: aumu - AtFr - VST , 0x0, 0x1029F
time to open unit = 92.647941 msecs

AudioUnit:0xC90000
CAComponent: 0x102AF ComponentDescription: aumu - VSTW - VST , 0x0, 0x102AF
time to open unit = 7.039503 msecs

-- 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.
  • Prev by Date: Re: [OT] Re: Mixer units
  • Next by Date: cleanup after CreateUI
  • Previous by thread: Re: how to start audiounits from scratch?
  • Next by thread: cleanup after CreateUI
  • Index(es):
    • Date
    • Thread