Re: 64bit processing possible?
Re: 64bit processing possible?
- Subject: Re: 64bit processing possible?
- From: Justin Carlson <email@hidden>
- Date: Thu, 30 Jul 2009 20:05:38 -0400
Hi, to everybody involved in this discussion. I'm going to jump in and
state my position regarding 'double support'.
Regarding AU development, I have agonized over the best format for
processing of several algorithms, for trivial and non-trivial
processes. I've entertained the idea of double support AUs, but I
never found a host that would open the plugins I'd built which publish
the format. If one does exist, do let me know. 'Double support' is on
the todo list for something that I have been working on, I don't see
the need to write a new or proprietary plugin spec since AUs provide
support for this.
Having said that - as Bill stated, modifying an AU to publish double
support is currently supported, and, to the best of my knowledge, the
AU spec is 100% ready and compatible in this regard - the plugins and
hosts just don't exist yet. double is the standard audio stream format
internally for my plugins (not all of them, but it is the standard
format). Within a plugin, it doesn't _usually_ make sense to do
several internal conversions from 32 to 64 and back, the same idea can
be applied to hosts to a potentially greater advantage. Such
conversions in a large mixer/plugin chain *will* impact performance in
a host where 'single support' and 'double support' is freely supported
(i.e. it is transparent to the user that the host is performing
conversions where necessary). From a practical standpoint, double
support will lead to a performance *increase* for hosts since there
will ultimately be fewer conversions. I don't consider floating point
precision conversion cheap in this context, some developers may. This
assumes that the mixer/plugin chain in use actually has a good balance
of plugins which render at double precision. Maybe that will help
convince host developers to consider adoption.
Not only is it a performance loss, but I am going to side with
Alejandro and say that there is (more importantly) an audible
difference, and that unnecessary conversions to single precision at
multiple stages in the signal path will degrade the signal when 64 bit
signals can be passed from point to point. Just to be clear, this
conversion is trivial for some applications and markets, but there are
people who will hear and appreciate the difference (primarily
professionals and musicians). I believe many plugin developers would
(over the course of a few years) adopt 'double support', if their
plugins render at double precision. Several plugins render at double
precision already (no surprise there). For a single conversion from 64
to 32, I can't imagine that the loss would be audible to... well,
anybody. In more complex signal paths with many processes, a moderate
number of conversions are audible (to my ears). Since complex signal
paths are quite common, it is safe to say that 'double support' would
benefit many users if the host itself used double precision as its
standard. I'm going (attempt to) avoid details in that regard if the
subject arises because the difference is subjective; If you're
skeptic, use your ears and measurement tools to determine what is the
best solution for your projects/works. That's what I have done. If you
and your users are 100% satisfied with single precision, why consider
changing your program?
For these reasons, I consider this a practical concern which affects
many (but not all) users. The users that will appreciate it the most
are the professionals and musicians (yes, I am intentionally avoiding
'marketing').
Regarding host support in this regard, the output format is a far
smaller concern in my eyes because:
1) Regardless of the internal render format, the signal needs to be
reduced at this stage
2) if it didn't, the physical limitations of any DAC or audio file
representation would still eclipse or equal the conversion's loss/
error. I consider file representations important since I can't think
of a common/non-proprietary, audio file format that is above 32 bits
(fixed or float) that can be opened by popular hosts on multiple
platforms.
3) The importance (given the current state of recording technologies)
is to maintain the signal's integrity during render and storage and to
minimize the error that is introduced along the way. Since we're
discussion high resolution audio, preservation in the rendering stages
will provide more audible benefit than the final output format. This
could be an obstacle for some projects, such as document based audio
file editors which store signals/intermediates below double precision,
as opposed to a DAW, which has many more running streams and more
complex signal paths.
Given those considerations, it is (in my eyes) acceptable to reduce
the precision when handing the signal off to AUHAL (as an example) and
for a host to be able to support 'double support' at this time.
If we're to go by history, host adoption as an initial step is going
to be the best way to get this technology to users.
Alejandro: ...would be nice to know what internal representation
does the plug-in has
Assumptions can be made by the host, but the 'best guess' will not be
correct in every case and this will compromise sound and performance.
If double support seems like it will be adopted, then it would be easy
enough to add an opcode for such an AU property without breaking
existing plugins, the plugin could then return an ASBD which describes
its internal render format (and the host would ignore some of the
fields). Would that cover everything you need to know in that regard,
or is there more information you'd like that I am overlooking?
Ev: 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.
As I see it: If hosts were to perform precision conversion where
necessary, then you could maintain compatibility with existing
commercial AUs. I may be wrong here as I'm going off memory, but you
could just evaluate ASBDs returned by the plugin, if 64 bit float is
published, then send it a 64 bit stream, if not, convert it to Float32
and pass it to the next plugin. If you have implemented this much in
your hosts, I would be willing to modify and load up some of my AUs in
Rax (or another host of yours) and inform you of problems, though it
depends on which week you catch me. I am not promising several days
worth of work or that I will send substantial works to you, but
something is better than nothing if you are considering support for 64
bit streams in your hosts. If you're interested, just follow up off-
list.
Anyhow, not everyone will appreciate, care for, or support the option.
Some will, and I would like to see 'double support' available.
Best,
Justin
_______________________________________________
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