all i can note is this. JACK on linux (where it was originally written) tries 32 bits-of-value per sample-as-integer first. Then it falls back through 24-in-32 and finally 16 bit formats.
the backends for CoreAudio don't try to do this, but use kAudioFormatFlagsNativeFloatPacked - still 32 bits per sample, but not 32 bit integers, just 24 bytes of real value. i don't know why the coreaudio code does this, but it wouldn't suprise if the 32-bits-of-value-as-integer version wasn't (isn't) available as an option. alternatively, it was just that 32 bit floating point is the canonical format for moving sample values around in all contemporary software applications, and it made more sense to just get it in that format directly from the AUHAL. how do you "ask coreaudio to record at 32 bits" ? On Wed, Apr 4, 2018 at 9:53 AM, Paul Sanders <[email protected]> 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 <[email protected]> > 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/pr > ivate/audio_midi_setup_screenshot.png > > TIA - Paul Sanders. > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
