Hello all,
Don’t know if I should have posted this to the USB list but as it
concerns the firmware of an audio 2.0 device I thought that there could
be people here able to give me some hints about my problems.
I’m working on the firmware of a device which is a USB audio 2.0 class
compliant d
configurations.
Sorry I don't have time for a more complete answer, but hopefully one or more
of the ideas above will give you something to investigate that might prove
useful.
It has been useful, thanks.
Brian Willoughby
Sound Consulting
On Mar 30, 2016, at 6:02 AM, Philippe Wicker
So I'll contact them to analyze it.
Anyway, thank you for your help.
Philippe
On 03/04/16 04:56, Brian Willoughby wrote:
Philippe,
On Mar 31, 2016, at 6:40 AM, Philippe Wicker
wrote:
On 31/03/16 07:17, Brian Willoughby wrote:
https://developer.apple.com/library/mac/technotes/tn2274/_in
This is how it can be done With MacOS:
https://stackoverflow.com/questions/3166783/how-to-increase-the-limit-of-maximum-open-files-in-c-on-mac-os-x/3214064#3214064
Maybe you can use the same APIs with iOS?
> On 20 Jul 2017, at 00:48, Paul Davis wrote:
>
> On OSX/MacOS, the limit can be modifie
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 u
> 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
