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 17:08:26 +0100
Sorry, post to the list.
On 04/04/2018 17:06, Paul Sanders wrote:
I don't have one of those but my hardware partners might, when they
return from their Easter break. But I think it's pretty clear from the
behaviour I have observed on macOS and Windows what is going on.
Paul Sanders.
On 04/04/2018 16:12, Philippe Wicker wrote:
From the screenshot of AMS it seems your device is operating at 32 bits
per sample. AMS just shows what the USB descriptors are telling of the
device capability. If you have a USB analyser you could check that
directly on the bus.
On 4 Apr 2018, at 16:44, Paul Sanders <email@hidden> wrote:
Yes, that's all true, but not relevant (well, not to me). I want the
device to be operating in 32 bit mode, regardless of how Core Audio
actually delivers the data.
Paul Sanders.
On 04/04/2018 15:09, Philippe Wicker wrote:
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).
...
_______________________________________________
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