Re: Audio recording bitdepth
Re: Audio recording bitdepth
- Subject: Re: Audio recording bitdepth
- From: Bjorn Roche <email@hidden>
- Date: Wed, 2 Dec 2009 10:41:33 -0500
Hey doug,
Thanks for your response. I find it a bit surprising that drivers do
the int<->float conversions, but I suppose this could be useful if
they can manage that on hardware. Still, Core Audio provides
converters for this purpose, and presumably those are canonical and
maybe could be used by the drivers. I presume that these use power of
2 multiplication/division as well.
FWIW, many other transforms are bit-transparent as well. I've done
some testing and
2^n
2^(n-1)
and several other transforms are bit transparent up to 24-bits as
well. I will report back when I've posted my results.
bjorn
On Dec 1, 2009, at 10:07 PM, Doug Wyatt wrote:
In the CoreAudio architecture, it is (normally) the driver that
performs the int<->float conversions. I can however speak to correct
behavior.
With 16-bit integer samples, a correct conversion from float is to
multiply by 32768.0f. A roundtrip int->float->int is lossless for
bit depths up to 24-bit, since IEEE floats have a 23 bit mantissa,
plus a sign bit, and we're simply converting by powers of 2. (In
fact in the int->float direction it is possible to produce the
correct floating point bit pattern using only integer arithmetic.)
There is no dithering in the stack (and were we to add it in the
future it would be opt-in).
Doug
On Nov 28, 2009, at 14:02 , Bjorn Roche wrote:
Hey all,
A recent discussion on another mailing list made me realize that I
may not recording (or playing back) audio in a bit-transparent way.
Currently, my app interacts with CoreAudio via floating point
numbers, and I'd like to keep it that way [1]. I would like to make
sure that integer-based linear-PCM files recorded or played back
(with the assumption of unity gain in between) on a device with the
same or higher bit-resolution remain bit-for-bit identical. For
example, a 16-bit file should play back via a 16-bit spidf
interface exactly the same as it is on the file, despite having
been converted to float and back to get into Core Audio (of course,
dither may also be an issue. I see nothing in the docs about dither).
Unfortunately, I cannot find any documentation about what int/
float/int transform is used by core audio, so I can't be sure
(without extremely painful testing) of what transform I should use
as an inverse transform. So if someone could let me know how Apple
handles these conversions, so I can properly invert them, I'd
really appreciate it.
thanks,
[1] this is because my app uses PortAudio, which is a portable API
that is built on top of APIs like CoreAudio. It interacts with the
AUHAL layer and does it's own conversions to non-float formats when
required. My app just speaks to it using float, and does it's own
conversions when reading files/playing back, which is not ideal,
since CoreAudio could give it the raw int-based data, but that's
the way things are.
-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave
_______________________________________________
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