• 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: Fat Binaries for AUs?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fat Binaries for AUs?


  • Subject: Re: Fat Binaries for AUs?
  • From: William Stewart <email@hidden>
  • Date: Mon, 6 Jun 2005 14:32:34 -0700


On 06/06/2005, at 12:12 PM, Urs Heckmann wrote:

Hiya,

will fat binaries also work for Audio Units?

Yes - the CA SDK that comes on the dev-machines include the changes we needed for universal arch. AUs. What changes you may ask? Simple enough - just changes in AUResource.r so that the component manager knows you have both Intel as well as PPC code. That was it for all of the sample AUs we ship in the SDK.


So, If you are using our SDK as a basis for your AUs and you have non- Altivec (plain C for G3 for instance), then it should be simply a matter of recompiling. But of course, this brings us to the next questions:

One data point that may help with this. AU Lab (which we shipped with Tiger) required no changes - just a recompilation for it to work. That app includes a data file (we use CF as a basis for this - that is endian safe), extensive UI (including some funky cocoa/carbon interaction) and a far bit of underlying C++ code. Once we fixed all the endian issues in the AudioFile API - these are now completely endian safe - AU Lab's record file (and the AUFilePlayer generator AU) "just worked". The MIDI Network driver works between PPC and Intel based machines, etc..

There are areas where we do have work to do - DSP optimisations will obviously be a big area for many of us on this list. However, there weren't any real surprises here, except maybe how much stuff just worked.

Will veclib survive?

Yes. There are sessions at WWDC about Intel specific topics, optimisations, etc... so if you are at the conference have a look at the updated schedule for these sessions.


How about Altivec code?

The CPUs we are using are standard Intel CPUs, so no Altivec units, but they do have SSE (as you'd expect) and that is where the floating point ops are done, so fp isn't too bad. As for porting Altivec code, I don't know what the plans are (if any) to assist in porting Altivec code - once more the WWDC sessions will provide good information here as well.


I'm sure that alot of information will surface over the coming days/ weeks as people really get going with this.

Bill

Any hoops we gotta expect?

Cheers,

;)  Urs


urs heckmann email@hidden www.u-he.com

_______________________________________________
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


--
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
________________________________________________________________________ __


_______________________________________________
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: 
 >Fat Binaries for AUs? (From: Urs Heckmann <email@hidden>)

  • Prev by Date: Fat Binaries for AUs?
  • Next by Date: Direct Monitoring: any news?
  • Previous by thread: Fat Binaries for AUs?
  • Next by thread: Re: Fat Binaries for AUs?
  • Index(es):
    • Date
    • Thread