Re: Don't ignore the 64 bit run time! (was Re: au won't register)
Re: Don't ignore the 64 bit run time! (was Re: au won't register)
- Subject: Re: Don't ignore the 64 bit run time! (was Re: au won't register)
- From: Jeff Moore <email@hidden>
- Date: Tue, 11 Dec 2007 17:04:38 -0800
On Dec 11, 2007, at 4:30 PM, Brian Willoughby wrote:
Ah. So the next logical question is whether AU is a 32-bit API or
both.
The entire Core Audio stack of APIs are both 32-bit and 64 bit
(although some old and deprecated APIs and any Carbon related stuff
aren't in 64 bit land).
Have we already discussed this on the list?
Don't know, but the 64 bit transition was a big topic at WWDC as I
recall. In fact if you missed it, you might want to go review some of
the sessions that discuss the transition, especially if you have a lot
of investment in Carbon code.
What does an AU developer have to do to enable 64-bit in an AU, that
could be tested in AULab?
Build a bundle that has all four architectures in it. The easiest way
to do that is to edit the archs build setting in your project to
target all four architectures.
Does the AU have properties or info marking it as 64-bit (other than
the usual executable flags) so that a host can distinguish the two?
A 64 bit process can only load 64 bit code. A 32 bit process can only
load 32 bit code. You can't mix and match. So, hosts don't generally
have to care. The loader will take care of making sure that only code
for the proper architecture gets loaded.
The best way to know ahead of time if a given bundle can be loaded
into the current process is to use
CFBundleCopyExecutableArchitectures() or
CFBundleLoadExecutableAndReturnError().
Can a 64-bit host load 32-bit AUs without too much special coding?
Absolutely not. In fact, it would be quite tedious and somewhat tricky
to do something like that. The 64 bit process would have to fork a 32
bit child process that handles the care and feeding of the 32 bit plug-
ins and then figure out a way to manage the child process's audio to
make sure the flow matches what the app is trying to achieve. Crossing
the process boundaries with audio data is a non-trivial thing, but not
impossible.
Given the complexity, I doubt very seriously if any applications will
actually implement this sort of scheme, but you never know.
Brian Willoughby
Sound Consulting
On Dec 11, 2007, at 12:45, Jeff Moore wrote:
Full blown 64 bit apps will be here sooner than you think. There are
some real advantages to running in 64 bit mode for applications. For
instance, on Intel hardware, you get twice as many registers. This
can boost throughput and/or calculation speed for some apps. Also,
those apps that have large sample banks and want to use more than
4GB of physical ram have no choice but to run in 64 bit mode.
To facilitate the transition, AULab and HALLab already run in 64 bit
mode today. Just not by default. To get these apps to run in 64 bit
mode, just get info on the application bundle (in /Developer/
Applications/Audio) and uncheck the "Open in 32 bit mode" box.
On Dec 11, 2007, at 12:23 PM, Brian Willoughby wrote:
Theoretically, support for 64-bit AU would require *every* AU host
to be rewritten as a 64-bit application. It's pretty tricky to
rewrite a GUI application for 64-bit, and all popular AU hosts have
a GUI. It's going to be a long time before there is any host that
would support a 64-bit AU anyway. This "limitation" is merely a
practicality.
On Dec 11, 2007, at 11:05, Daniel Oberhoff wrote:
I finally figured I had 64bit set (x86_64), assuming leopard is all
64bit. But it isn't it just supports 64bit, but doesn't use it in
AUs. Which I suppose is two avoid deprecating lots of installed AUs.
--
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