For proprietary hardware, you will certainly need hog mode. As I mentioned, pay careful attention to how you open the input device, which device you're accessing, and the scope. I find that it helps to print the format information for all scopes of all devices, both before and after my format changes. This usually reveals why the sample rate or format is not as expected.
I know that you said there is no error message, but be sure that your code checks for errors on all CoreAudio calls, not just the ones that you think are important. When reviewing code that isn't working, I almost always find that the developer is ignoring an error from some other function that ends up being critical. The modern way to open an input device is using an AUHAL output device and enabling its input scope on bus 1. So, add bus as a parameter to pay careful attention to, as well as scope and which device you're accessing. AUHAL involves a lot of complex mechanisms behind the scenes that you might not need. Earlier versions of CoreAudio allowed the input device to be opened directly, without requiring a paired output, and without the necessary AUConverter that AUHAL needs. If you do not need audio output, then you might look for the older, input-only API. I cannot recall whether I have used it lately, although I have been exploring the limits of CoreAudio in the past year. Brian Willoughby Sound Consulting On May 31, 2017, at 10:46 AM, Hubert Pietrzykowski wrote: > Thank you very much for your suggestions, Brian. I totally agree with your > points. While I understand the IEEE754-compliant float representation and the > fact that 24-bit integer samples can be embedded in a lossless fashion in > 32-bit float, the application I write really needs to be able to capture > entire 32-bits intact. It is supposed to be a proprietary app bundled with > high-end ADC coming from one of the leading manufacturers. It does not need > to work with any audio device but the one it was designed for. Among > requirements, some point down the road we need to be able to record DSD > stream (embedded in the 32-bit integers, all bits meaningful - sort of a > non-audio data you mentioned, non-PCM in this case which makes your point > valid), so it looks like I really need to pursue that 32-bit integer path. > _______________________________________________ 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]
