On Dec 10, 2022, at 2:07 PM, Gagan Sidhu via Coreaudio-api <[email protected]> wrote: > how does one implement an SPDIF toggle?
What is a "toggle"? Are you talking about an Enable, or a Mute, or some other sort of switch? I've not heard the term used within the CoreAudio universe, so it's a difficult question to answer without more information. ... and then, what is an "SPDIF toggle"? Perhaps you should step up a conceptual level and describe what you are trying to accomplish. Are you creating support for SPDIF? Are you trying to gain access to pre-existing support for SPDIF? Are you even sure that you need SPDIF, per se, and not merely a general CoreAudio stream? > we could use an IOAudioToggleControl, sure, but i noticed > kIOAudioSelectorControlSelectionValueSPDIF is in an enum. I am not familiar with the use-case for IOAudioToggleControl, so I'd probably have to see an example (code or user interface) before I could attempt to comment. Looking at the headers that define kIOAudioSelectorControlSelectionValueSPDIF, it looks to me like an Audio Selector Control is a way to choose a particular type of connector on a physical audio interface connection. For example, the typical MacBook has internal speakers and a headphone jack, but only one audio output that can be directed to one or the other of these two destinations. There is thus an Audio Selector Control that allows an application to query or set the Device connection type to kIOAudioSelectorControlSelectionValueInternalSpeaker or kIOAudioSelectorControlSelectionValueHeadphones. Different physical hardware interfaces will have different valid options available. kIOAudioSelectorControlSelectionValueSPDIF is an enum because it is just one of eight possible selections for an Audio Selector Control. Looking at the header comments, three options are output-specitic, three are input-specific, and two are common to both output and input. SPDIF is one of the types that happens to be valid for both input and output. One enum is for 'none', but we won't count that. Thus, for physical inputs, there are five valid options, and a given audio interface device will have some number of these. Same for physical outputs - five valid options in total, two in common with input and three unique to output - with a given audio interface device allowing one or more of these. It's probably worth pointing out a few things. You can't force physical hardware into SPDIF mode unless its electronics are actually designed to support it. This setting won't really be appropriate unless your code is talking directly to a CoreAudio physical device. Granted, most of your code might be dealing with a CoreAudio stream before it reaches the hardware, and so it's worth pointing out that SPDIF isn't a concern until the audio stream reaches a physical interface. Finally, there's almost surely going to be a hardware-specific driver that determines whether SPDIF is available as an option or not, otherwise selecting it will probably return an error. There is probably some mapping between USB Audio Class and CoreAudio where the macOS driver for all UAC devices can automatically translate - however, I'm not sure whether UAC actually has this, so it's probably an avenue where more research is needed (the USB to CoreAudio aspect, that is). Non-USB audio interfaces will surely need a custom driver to facilitate support for S/PDIF. I did not immediately see a way to query a device for a list of Audio Selector Control types that are available on a specific input or output stream, but knowing CoreAudio there is probably a way. > and if my usage is appropriate, another question would be about handling a > massive number of controls that involve monitor modes. What exactly are you trying to do here? CoreAudio might not be appropriate for monitor modes, at least not unless they represent different I/O Selections. The answer probably depends upon whether changing monitor modes is more of an audio processing change or a physical patching change (or both). There seems to be some mapping between the USB Audio Class Descriptors and CoreAudio controls, at least for some types of features, but I've not looked too deeply into that. Often, the mapping loses too much in the translation, so there are probably limits to how fancy you can get here. > right now we have a Level and Toggle control, and yes we can use the more > generic IOAudioControl::create, but it seems to me there hasn’t been anyone > asking questions of this nature. > > the closest was Yves in 2011: > https://lists.apple.com/archives/coreaudio-api/2011/Mar/msg00004.html > > i found willoughby’s answer very interesting in terms of generalisation. for > example, ALSA’s snd_kcontrol_new requires an ‘info’ and ‘get’ function. > > yet for coreaudio there is no equivalent. it is almost as if, as long as we > can specify the hardware control for setting things (like alsa’s put), that > “coreaudio will take care of the rest”. It's incredibly difficult to design generic support that includes every possible variation and yet automates the mapping between different systems. i.e. The more capable and flexible a design is, the less it can be automatically mapped to some other paradigm. Apple has done quite a good job of designing CoreAudio so that USB Audio Class Devices can be fully supported, but mapping to other systems (ALSA?) may reveal a mismatch between the available building blocks in each system. If I were working on this, I'd purchase some of the most complex USB Audio Class Devices available on the market - that are known to be (fully) supported by macOS - and then take a detailed look at both the USB Descriptors and the CoreAudio objects that those descriptors are translated too. Apple provides a couple of tools like HAL Lab that allow visibility into the CoreAudio details for specific devices, but you can also write code to walk the device and object trees to see how things are put together. Once you get familiar with a complicated device, this should give you an idea of how things work in CoreAudio, and then via the header files and comments you can perhaps expand on the specifics that you're trying to support. I've had good luck writing custom code to query and display as much data as possible about my particular setups. Brian Willoughby > On Sat, Dec 10, 2022 at 1:51 PM Gagan Sidhu via Coreaudio-api > <[email protected]> wrote: >> [...] assistance in wrapping this ALSA code to coreaudio (i’m using osx < 11) >> >> https://github.com/i3roly/CMI8788 >> >> Thanks, >> Gagan _______________________________________________ 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]
