Re: Driving a USB device at 32 bits per sample
Re: Driving a USB device at 32 bits per sample
- Subject: Re: Driving a USB device at 32 bits per sample
- From: Paul Davis <email@hidden>
- Date: Wed, 04 Apr 2018 10:06:26 -0400
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@hidden>
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@hidden>
> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden