Re: 64bit processing possible?
Re: 64bit processing possible?
- Subject: Re: 64bit processing possible?
- From: William Stewart <email@hidden>
- Date: Thu, 30 Jul 2009 12:49:37 -0700
ok - but I don't see why this is such an issue.
AUHAL is interfacing through the HAL to the audio driver. No audio
hardware that I know of can even use all of the 24bits of resolution
that can be represented in a 32bit float.
If you keep your whole signal processing chain as doubles (which you
can easily do with audio units if you build your own) - and I am sure
that there would be some 3rd party interest to add to this - you have
at some point to go down to 24bit output (or come from 24 bit input).
So, exactly why is AUHAL a problem (or even a roadblock) here?
Bill
On Jul 29, 2009, at 12:27 PM, Evan Olcott wrote:
On Jul 29, 2009, at 2:04 PM, email@hidden
wrote:
The best next step here is for some industrious developer to create a
double-precision AU host and go from there. It's a bit of a chicken-
and-egg situation, but it would seem to start the ball rolling.
Coming from the host-development side (which we do with a small
handful of our products, Rax in particular), I can tell you that we
HAVE tried this and researched it, and our roadblock in the end is
the AUHAL drivers. Even if we WERE able to make the entirety of the
stream double precision, not only would we lose access to almost
every commercial AU, it seems to be brought down to (at least)
single-precision internally the AUHAL. We have yet to come across an
AUHAL driver that supports a 64-bit AudioBasicStreamDescription as
the input format. The drivers we've analyzed seem to convert their
data streams to 24-bit integer on the outgoing side, so they take
the single precision and convert that to a more efficient data
stream. 64-bits with multiple channels is a pretty hot data stream -
takes a wide pipe to push that all through.
That said, it's not like we've seen every driver out there. If there
IS a double-precision clean AUHAL driver out there (that can be used
by third-party developers like us), please let us know - we'd look
forward to working with it. We'll be the guinea pig if it gets
double-precision AUs written.
Also note: the 64-bit operating system will effectively obsolete VST
support, as their interfaces are written (almost always) in Carbon.
Carbon libraries are not available to apps that are 64-bit clean. We
are going down the 64-bit clean path, as every app eventually will,
and Carbon.framework will be unavailable. So unless someone
(Steinberg?) finds a way to update the VST libraries to not access
Carbon.framework, update their headers to properly use the 64-bit
memory access (does VST3 do this?) and to use Cocoa GUIs instead of
Carbon (up to the individual developers), VST plugs are a dead end.
Audio Units seem to be the only path forward. If someone could prove
me wrong, we would really really like to know.
Ev
Senior Software Developer
Audiofile Engineering
http://www.audiofile-engineering.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
_______________________________________________
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