How do I programatically query the audio card in a Mac/PC to find sample rate, bit depth and other audio card parameters?

I am trying to derive the audio sample rate and bit depth (maybe number of channels) of my audio card (or specified "device") is set to within a script. Is there a way to query these value? I want the script to be able to process the audio in "sync" with the audio stream coming from my specified device. Currently I have to know the parameters an modify my scripts accordingly.

[Walter Roberson]

I have been digging into some specifications for some sound chips, trying to find the actual supported hardware rates.... the most I have been able to come up with is hints that the output of some sound chips depends on the clock rate, with a range of clock rates being supported.

The question is starting to feel like one of those questions asking "exactly" what rate an I/O device can run when it turns out that the rate can be integer multiples of basic frequency divided by a register. Along the lines of "Well it is true that this rs232 port cannot handle exactly 81957 baud, but by using the appropriate combinations of multipliers and dividers it can handle 81956.994125 or 81957.0063875 baud" and you saying "See! I told you it had important limitations! I should have been able to query to find out exactly what it supports!".

Answer 1

[Walter Roberson]

I tried digging further into Apple's audio interface to see if I could find device descriptors of supported audio rates.

The descriptors that are made available for listing devices... have no information about rates, and there is nothing I can find in the relevant classes that would permit using a device descriptor to find the supported rates.

I also see https://rogueamoeba.com/support/knowledgebase/?showArticle=Loopback-Aggregate-Device-Drift-Correction which talks about aggregate devices, which might possibly be for a newer MacOS release than I have installed. The drift correction permits tying a group of devices to the clock rate of a selected device so that the devices do not lose synchronization. The documentation there explicitly says that two hardware devices with the same nominal rate are not going to stay synchronized without a common clock. Note that the solution is not given as tying them to some shared master system clock: the solution is given as tying them to any chosen device even as it drifts . This implies that the tuning is not "digital", but rather hardware waveform level. And that makes the current hardware output rate unknowable (unless there is some kind of feedback measurement that I missed.)

[Richard Keniuk]

Thanks for your help Walter,

Did you find anything on the current set sample rate for the audio card? I was not asking about the possible rates, but this is good. I am trying to write scripts that will interact with the audio card at their current settings to avoid digital artifacts in my collected data. Still, thanks for the work. How would I access the descriptors from Matlab?

[Richard Keniuk]

Added: I have apps that track the audio card settings so I know they're there somewhere.

[Walter Roberson]

The information I am finding seems to relate to a unified iOS and Mac audio environment that might possibly only support MacOS Catalyst and later (which I do not recognize to be honest)

https://developer.apple.com/documentation/avfaudio/avaudiosession/1616499-samplerate

https://developer.apple.com/forums/thread/69572

[Walter Roberson]

The older MacOS interface appears to be described at https://audiokitpro.com/auv3-midi-tutorial-part2/ in terms of AudioUnit instead of newer AUAudioUnit

You have to go fairly fair down in the Apple Heirarchy to deal with actual device rate capacilities. Apple designed in terms of any number of user-selectable conversion steps (including rate conversions) until finally you hit the Hardware Abstraction Layer and the last step in that layer is for outputs to do rate conversions .

The channels do not involve sending just streams of samples that are to be blindly converted according to the then-current output rate: the channels involve sending blocks of signals that have timing information accompanying them in the channels, and then at the last minute the hardware abstraction converts for the actual hardware capability. The actual hardware capability is designed to be mostly opaque.

https://developer.apple.com/library/archive/technotes/tn2091/_index.html

2022-ish Mac devices added a higher speed output device that is configured through midi controls; https://support.apple.com/en-ca/HT212854

[Richard Keniuk]

Walter... Sorry for the slow response. You are a wealth of knowledge (or a great googler ;-) ). Thanks for the links. Some are applicable for other things I've been experiencing. The discussion on drift correction is important. Much of the issues when I collect audio from my Matlab script look to maybe be drift issues (on both Mac and PC). I use Matlab generated wav/flac audio test tone files (precise 16, 24, and 32bit tones) and can play those with different apps and in-turn loop them back to Matlab on the Mac using Sound Siphon and various methods on PC (to avoid the Windows CAudioLimiter). I use the tones to confirm that I'm getting a near as possible "digital" loop back from the players. Then I can use the players to analyze streaming encoders (or in the case of my question) analyzing the functionality of the individual players and their settings. I find that many of the players need to be aware (as well as Matlab) of the (at least sample frequency) parameters of the sound device they're playing into. When that sample rate is mismatched the frequency response suffers do to poor sample rate conversion (or no SRC). Many times it also sets up spurs. In this 24bit, 192kHz samplerate white noise file (ruler flat response to 96kHz) while being played at 44.1kHz (Matlab collecting samples at 44.1kHz).

Or the spurious taking the 24bit file down to just over 16bit performance (SNR is 146dB on the sample rate aligned version).

These aspects are what blurr high-end audio, and add distortion. Mixing new "HD" audio files and standard CD audio on a given player will force you to constantly adjust your samplerate on the Mac/PC/Player to match (you can use samplerate converters to up/down convert to your rate of choice) but this is rather tedious and many times overlooked.

Whoop... Dizzy standing on the soapbox... ;-)

Thanks for the inputs. Maybe someone knows something about reading sample rate of the audio device in Windows.