Mailing Lists: Apple Mailing Lists
 Image of Mac OS face in stamp
Re: 64bit processing possible?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64bit processing possible?


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





















Visit the Apple Store online or at retail locations.

1-800-MY-APPLE


Contact Apple | Terms of Use | Privacy Policy


Copyright © 2011 Apple Inc. All rights reserved.