Re: Audio recording bitdepth
Re: Audio recording bitdepth
- Subject: Re: Audio recording bitdepth
- From: Doug Wyatt <email@hidden>
- Date: Tue, 1 Dec 2009 19:07:39 -0800
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.
_______________________________________________
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