AFAIK CoreAudio don’t allow a user to get the raw samples from the device, it always provide audio data with a 32 bit float format (single precision). Device native PCM data are converted at some point (within the driver? Or maybe in the HAL?) to this float format before being delivered to the user. It’s also true in the other direction, you have to provide 32 bit float to the device. These float data are converted to whatever the device needs at some point. If you need to get or send raw data then you are limited to 24 bit integer which is the largest bit-size you can encode in a lossless manner within a float (24 bits is the size of the float mantissa).
> On 4 Apr 2018, at 15:53, Paul Sanders <p.sand...@alpinesoft.co.uk> wrote: > > Crikey, talk about an inflammatory response! Doesn't tell me anything I > don't already know, either. > > I think I mentioned that I have my reasons - which I do not wish to share at > this stage - for wanting Core Audio to tell the card to transfer 32 bit > samples (in 32 bit containers) and I would like to know if it is possible to > get it to do it (and if not, why not). And that's all there is to it. > > Paul Sanders > > > On 04/04/2018 13:38, Paul Davis wrote: > > Lets differentiate between a couple of things: > > 1) 32 bits used to transfer the sample value between the audio interface and > the CPU > 2) the analog-to-digital converter generating 32 bits of information for each > sample value > > The first one is relatively common - there are many interfaces that do this. > They pack 24 bits of sample value into a 32 bit unit, aligned either LSB or > MSB, and occasionally (hello, RME!) use the other 8 bits for carrying other > information (e.g. timecode) > > The second one is completely absurd. 32 bits of information means that the > least significant bits are determined by atomic brownian motion. Not only is > it not possible that the converter is measuring this, even if it could you > wouldn't be interested. Most 24 bit converters have a hard time actually > getting to full 24 bit resolution, so the idea that you can go 7 or 8 orders > of magnitude beyond that (each extra bit doubles the resolution) is absurd > unless you're doing science. > > So, which situation are you actually dealing with, and are you clear on how > absurd 32 bits of "value" per sample is? > > > On Wed, Apr 4, 2018 at 6:39 AM, Paul Sanders <p.sand...@alpinesoft.co.uk > <mailto:p.sand...@alpinesoft.co.uk>> wrote: > > Hello again, > > Same person, different question. > > I have a USB ADC here that can do upto 32 bits per sample and indeed it shows > up as such when you ask it what it can do, but if you ask Core Audio to > record at 32 bits then it still tells the device to operate at 24 bits. Is > this intentional and is there anything that can be done about it? > > I have a legitimate reason for asking but it is commercially sensitive so I > won't share it here. I am talking to the device through AUHal but I don't > think that's relevant. Tested on Sierra 10.12.6 > > Screenshot from Audio MIDI Setup here: > http://www.alpinesoft.co.uk/private/audio_midi_setup_screenshot.png > <http://www.alpinesoft.co.uk/private/audio_midi_setup_screenshot.png> > > TIA - Paul Sanders. > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list (Coreaudioemail@example.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/pwicker%40mac.com > > This email sent to pwic...@mac.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudiofirstname.lastname@example.org) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com