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 Sanders <email@hidden>
- Date: Wed, 04 Apr 2018 15:42:19 +0100
No, it didn't surprise me either [when Core Audio didn't do what I
wanted]. They probably didn't see any point.
> how do you "ask coreaudio to record at 32 bits" ?
Basically, something lke this (assuming the device supports it):
int n_channels = 2;
AudioStreamBasicDescription asbd = { };
asbd.mSampleRate = 96000; // say
asbd.mFormatID = kAudioFormatLinearPCM;
asbd.mFormatFlags = kAudioFormatFlagIsSignedInteger |
kAudioFormatFlagIsPacked;
asbd.mBytesPerPacket = n_channels * 4;
asbd.mFramesPerPacket = 1;
asbd.mBytesPerFrame = asbd.mBytesPerPacket;
asbd.mChannelsPerFrame = n_channels;
asbd.mBitsPerChannel = 32;
asbd.mReserved = 0;
UInt32 nbytes = sizeof (asbd );
AudioObjectPropertyAddress pa;
pa.mSelector = kAudioStreamPropertyPhysicalFormat;
pa.mScope = kAudioObjectPropertyScopeGlobal;
pa.mElement = kAudioObjectPropertyElementMaster;
OSStatus status = AudioObjectSetPropertyData (stream_id, &pa, 0,
NULL, sizeof (AudioStreamBasicDescription), asbd);
Where stream_id was obtained like this:
pa.mSelector = kAudioDevicePropertyStreams;
pa.mScope = (for_input) ? kAudioDevicePropertyScopeInput :
kAudioDevicePropertyScopeOutput;
pa.mElement = kAudioObjectPropertyElementMaster;
status = AudioObjectGetPropertyDataSize (device_id, &pa, 0, NULL,
&nbytes);
if (status == noErr)
{
AudioStreamID *stream_ids = (AudioStreamID *) malloc (nbytes);
status = AudioObjectGetPropertyData (device_id, &pa, 0, NULL,
&nbytes, stream_ids);
...
}
I know that this code is working because Audio MIDI Setup shows the
device is configured in 32 bit mode. But the device itself doesn't
think so, and I know that it works correctly because it does so on
Windows (via WASAPI).
On 04/04/2018 15:06, Paul Davis wrote:
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
<mailto: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
<mailto: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/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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden