Re: Native Device Formats
Re: Native Device Formats
- Subject: Re: Native Device Formats
- From: William Stewart <email@hidden>
- Date: Fri, 13 Jun 2008 19:24:33 -0700
Just one point to add here.
Core Audio by default provides data to and from the client as 32 bit
floats - we call this the canonical format as this is used generically
throughout the system regardless of the device present. However, you
also have the ability to deal directly with the native format of the
device - there is direct support for this in the AudioHardware.h
properties for devices.
It is a common misconception that core audio's "canonical" format for
the client is the "only" format and it is usually in comparison to
ASIO that that misconception is repeated. So, I don't want to buy into
this interesting debate, but I do want to correct the unstated
assertion that you cannot deal in the native bits of the underlying
device with core audio. You can. There are some comments in the header
<CoreAudio/AudioHardware.h> that can help you out with this.
Bill
On Jun 9, 2008, at 3:38 AM, Mikael Hakman wrote:
Richard, Brian - a very interesting topic, this one. I understand
what you are saying, I agree with some of it, and I disagree with
other parts. In particular I disagree with parts that are pure
assertions and/or assumptions without any rational explanation or
proof, such as e.g. that using inclusive [-1.0, +1.0] range mapping
when working with CD data would cause distortion and therefore we
are forced to use [-1.0, +1.0) exclusive mapping. If you use
lossless mapping from signed integers stored on a CD to float, which
[-1.0, +1.0] mapping is, and you interpret the numbers in the same
way as they are meant to be processed by a DAC, then no distortion
will occur. Likewise the assertion that suitability or convenience
of a particular mapping depends on the source of digital audio is
given without any rational explanation, verifiable support or proof.
It would be a good argument if it was true, and this is the reason
why you use it.
For most parts you are describing how thing are, not why they are
this way, which was my original question. The closest thing to an
explanation is Richard's assertion that this +1.0 exclusive mapping
provides "a nice simple mapping between the integer form and the
mantissa of the float", meaning, I suppose, that you can do the
conversion by bit-twiddling (faster) instead of division and
multiplication (slower). This is true, but equally nice simple
mapping exists even when using inclusive +1.0 mapping.
However, my purpose here is not to argue but to have an enlightening
discussion from which we all can hopefully learn something. First of
all, I've been using ASIO in a large number of projects. ASIO allows
you to output (and input) the exact digital values (the bits) to
(from) the digital wire. Therefore you are free to work with any
representation you want in your application and then it is your
responsibility to convert to (from) the signed integer values of
appropriate for your project bit-width before outputting (after
inputting). In all projects I used therefore inclusive [-1.0, +1.0]
range and then converted to/from 16-bit or 24-bit signed integer
representation just before (after) outputting (inputting). I didn't
notice any problems, whatsoever, with this. On the contrary, as I
said before, this is very convenient, and less error prone than this
exclusive +1.0 mapping.
My main business in this context is not creating music or other
audio, but precision testing of audio devices and audio algorithms
(including DAC/ADC devices). This is done by pumping specially
designed signals through a device or an algorithm under the test,
recording the resulting signals, and then analysing the signals. My
tests give much more exhaustive information about a device or an
algorithm than the few simple numbers normally published in the
specs. For example, a THD+N of -100 dB at 1000 Hz during a steady-
state test don't tell you much. THD at 12 kHz during the first few
milliseconds or even less (attack time) after a saxophone starts
playing from a complete silence, is much more relevant. My test
procedures go down to about -320 dB (the theoretical but
experimentally verified limit of Float64 computations). If there
where any problems with this inclusive +1.0 mapping then I would see
it. I don't.
So, what is causing this exclusive +1.0 confusion, or as Richard
express it, "this marvellous old can of worms"? Consider a series of
numbers consisting of following values: +1.0, -1.0, +1.0, -1.0, etc.
What signal does this series represent? It represents a pure sine
wave with a frequency of half sample rate, sampled at ½ PI, ¾ PI
etc. Also, its DC offset is exactly 0. When storing these numbers in
computer, the wave gets congested by -320 dB THD if using Float64
and by THD -192 dB when using Float32. Whether this distortion is
harmonic or not is arguable.
Now, consider the following series of signed 24-bit binary integers:
0x7fffff, 0x800000, 0x7fffff, 0x800000, etc. The values are the
maximum and the minimum of a 24-bit number, and these are the values
transmitted by S/PDIF and processed by a DAC. What does this signal
represent? Two answers are possible.
If you say that this series represent the same wave as the above
+1.0,-1.0 series then you must withstand that the binary integer
value 0x0 is not signal value 0. The signal value zero is half way
between binary 0x0 and 0xffffff - i.e. it is not expressible as a
bit combination. This doesn't mean that you cannot output silence. A
series of any constant numbers will be interpreted as a silence with
a corresponding DC offset. A series of 0x0:s will be interpreted as
a silence with DC offset ½ bit out of 24.
If you, on the other hand, require the signal value 0 to be
represented by binary 0x0 then the consequence is that the above
integer series doesn't represent pure sine wave. This is because a
pure sine wave is symmetrical around 0 but the above series isn't -
negative half is larger by 1 bit than the positive half. It is a
distorted sine wave but only if you persist that binary 0x0 shall be
signal value 0. There you have your distortion.
The interesting questions now are:
1. What would you like it to be?
2. What does current DAC semiconductor components do? How do they
interpret this series?
Depending on the answer to the above questions, you could arrive
either to conclusion that inclusive [-1.0, +1.0] mapping is very
adequate, or that you shouldn't use the most negative integer value
at all in which case the inclusive mapping is still ok.
Regards/Mikael
_______________________________________________
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