USB audio

[c-o-pr]

I am not sure of an in-depth guide here, sorry!

I happened to come across it the other day and thought I would save it with my other links

@james090500

Bad news for me: @Feartech link is not a guide for building layouts for Reaktek USB audio.

In the first step, you need to collect codec data from the system (under Linux, say) but I quickly found that USB audio controller codec config doesn't present anything like what this guide requires. The onboard HDMI audio can be handled by this guide. For example, in my case I have RocketLake UHD and AMD 5700 HDMI audio which fits the config schema needed to create layouts with these tools. But my sound ports are ALC4080 is a USB codec that works completely differently. So these tools seem like a dead end for USB audio.

Over at the 2017-era TonyMacx86 RealTek Audio Guide forum, there's a subsection on AppleHDA Realtek Audio which seems like it might be helpful. However, a quick look shows it refers to github resources that are 7 years old, Clover oriented, and the USB audio customization details involve copying existing configs and rewriting various hex values from X to Y, with no deeper view as to where these numbers come from and what they mean. It's very cryptic. It might work, but shows signs of being out of date. I'll have to look at this a bit more to see if it's still a prospect.

 

[c-o-pr]

This extremely detailed post by CaseySJ covers the same ground as the how-to links but in context of 2022 Asus z690 with Realtek S1120A. In his post, he pulls config out of /proc/asound/card2/codec#0, which my board has... He doesn't explain how he chose that device. Mine is listed as ATI 6xx series controller with HDMI. My board has two possible HDMI output devices: AMD dGPU and Intel iGPU. But maybe the ATI 6xx actually refers to the Realtek 4080?

I'll drop the subject here. I just wanted post followup from today's explorations and leave this thread with info in context.

 

[etorix]

I need a novel layout for a z590 board with Realtek ALC4080. This is a variant of venerable ALC1220, so I hope I can dump my pin config and compare with an existing 1220 layout to build my layout.

As far as I know, ALC4080 is a USB-based audio codec, and only a "successor" to or "variant" of ALC1220 in meaningless marketing lingo. No layout-id should be required, but a proper USB map with a port dedicated to it.

 

[c-o-pr]

As far as I know, ALC4080 is a USB-based audio codec, and only a "successor" to or "variant" of ALC1220 in meaningless marketing lingo. No layout-id should be required, but a proper USB map with a port dedicated to it.

That's right.

Sound works by default with no layout-id specified, however...

- None of ports are labeled, they appear as generic USB Audio.

- Keyboard volume control doesn't track the front vs rear headphone jack's; keyboard volume works for rear headphone, but not for front.

- Choosing various layout-ids doesn't affect the above.

- Specifying any layout-id instead of letting AppleALC decide causes macOS process kernel_task to eat 75% of CPU (per Activity Monitor) running code related to audio DAC (per Spindump). This is a substantial waste load that reduces single thread performance available to applications by 1/5. That's as much as major CPU upgrade.

I'm carefully reading multiple guides including AppleALC github codec how-to, @CaseySJ writeup for codec on Asus z690 Proart, and legacy docs such as "Idiots Guide to Lilu" and every step leads to more complexity and confusing results, so I can see why no one has a quick story on this topic.

@james090500, pls do post your experience per above, TIA

 

[c-o-pr]

OK holy carp, so does AppleALC have anything to do with USB audio?

I have read hundreds of pages of diatribe on controllers, codecs, patching, layouts, but nowhere is USB ever mentioned. When I go looking for a dump of my sound controller in Linux, the /proc/asound/card1/... has a completely different format than the two other audio controllers.

If I disable AppleALC entirely, sound works per my previous message.

I came across a post in InsanelyMac which says
"USB audio has nothing to do with AppleALC."

After 100,000 or so words on the topic spanning years of learning and lore, and many guides and dialogs, posts never say anything like: IF YOU HAVE USB AUDIO, IGNORE THIS LORE. Maybe it's obvious and it goes without saying? Even Dortania says nothing about this, it heads you into searching for HDEF device with gfxunil and trying layout-ids. If you have HDMI audio which everyone does these days, you will find a device with HDEF... Maybe in both iGPU and dGPU.

[Edit: the fact that guides have you look for a PCI device as part of the prep should have been a big clue to me: If audio is behind USB, then it won't have its own branch from the PCI Root. My view was that AppleALC was giving me system audio in the form a layout so from there is was just what sound chip is invoked?]

What happens with HDMI audio via GPUs? It this handled by WhateverGreen?

 

[c-o-pr]

For anyone else trying to understand USB audio config...

A years-old post on these forums mentioned there once was (maybe still is) a way to enhance USB audio device config using a development kit from Apple, including renaming interfaces to match a build.

ReadMe.txt

Demonstrates how to override certain properties of a USB audio device using a codeless kernel extension.

developer.apple.com

This project is a codeless kext that allows it to override certain properties of the USB audio device. There is only a plist file and localized strings. To specify a specific audio device for this sample code project to use, you will need to modify the project's Info.plist file. Modify the Info.plist entry IOPropertyMatch to match to the hex values of the idVendor and idProduct of your device. Also modify bInterfaceNumber and bConfigurationValue to match to the USB interfaces.
You can discover these values by using developer applications like IORegistryExplorer or USBProber.

Based on the Readme, it looks like this config can only create suitable descriptions of the USB audio interfaces, and offers a hook to a 3rd party (e.g., device vendor, not you) configuration app that can appear as a hook in Audio MIDI Setup to do further configuration.

It's vague as to whether any of this might help with special behaviors like automatic Mute and Volume Control per headphone interfaces. The prospects don't look too good.

Maybe a 3rd party app like Rogue Amoeba SoundSource can help with some additional functions.

I think Big Sur / Monterey still have a user folder supporting 3rd party extensions, so hoping this approach still works.

 

[etorix]

OK holy carp, so does AppleALC have anything to do with USB audio?

There is a smaller AppleALCU.kext for USB audio only, which can be used as an alternative to AppleALC.kext. Its code is also included in AppleALC. So AppleALC has something to do with USB audio.

What happens with HDMI audio via GPUs? It this handled by WhateverGreen?

From WhateverGreen documentation, AppleALC is still responsible for the audio part.

How do I get HDMI audio to work?
In general it should be enough to rely on AppleALC automatic HDAU correction. It renames the device to HDAU, and injects missing layout-id and hda-gfx (starting with onboard-1) properties. This will not work well with two or more cards of different vendors (e.g. NVIDIA and ATI/AMD), please manually inject the properties in such a case. You may also use -radnoaudio boot argument or no-audio-autofix GPU controller property to explicitly disable any audio-related property changes.
For identifiers not present in AppleHDAController and AppleHDA you have to add necessary kext patches, see AppleALC example for 290X.

 

[etorix]

On second thought, maybe AppleALC really has nothing to do with USB audio, and AppleALCU is the part which deals with HDMI audio and other audio functions which do not relate to the audio hardware.

 

[Feartech]

@james090500

Bad news for me: @Feartech link is not a guide for building layouts for Reaktek USB audio.

In the first step, you need to collect codec data from the system (under Linux, say) but I quickly found that USB audio controller codec config doesn't present anything like what this guide requires. The onboard HDMI audio can be handled by this guide. For example, in my case I have RocketLake UHD and AMD 5700 HDMI audio which fits the config schema needed to create layouts with these tools. But my sound ports are ALC4080 is a USB codec that works completely differently. So these tools seem like a dead end for USB audio.

Over at the 2017-era TonyMacx86 RealTek Audio Guide forum, there's a subsection on AppleHDA Realtek Audio which seems like it might be helpful. However, a quick look shows it refers to github resources that are 7 years old, Clover oriented, and the USB audio customization details involve copying existing configs and rewriting various hex values from X to Y, with no deeper view as to where these numbers come from and what they mean. It's very cryptic. It might work, but shows signs of being out of date. I'll have to look at this a bit more to see if it's still a prospect.

As far as I know, ALC4080 is a USB-based audio codec, and only a "successor" to or "variant" of ALC1220 in meaningless marketing lingo. No layout-id should be required, but a proper USB map with a port dedicated to it.

I have given you your own thread

 

[c-o-pr]

No luck getting the old Sample USB Audio config to work under 12.4

Steps:

1. Looked up my Realtek USB device vendor and product IDs in ioreg and coverted from hex to decimal
   — cross-checked the ids provided in another user's Sample with a linux USB vendor database to be sure I'm getting the codes right.
2. Edited the Sample.kext/Contents/Info.plist to add IDs and rename config
   — cross checked various top level boilerplate config keys with a more modern kext and updated
3. Placed Sample.kext in /Library/Extensions (Since SSV hardening, /S/L/E is off limits)
4. chown -R root:wheel /L/E/Sample.kext & touch /L/E
5. Disabled SIP in OC and verified SIP status

The config change doesn't take.

It's not clear to me if kmutil (kext manager command) should show "loaded" status for codeless kexts, but the kext is not reported as loaded. If I load it by hand, the command runs quietly.

I played around with locally signing the kext and System Report > Extensions reports different signing status...

Overall: FAIL

Maybe the way of massaging USB audio devices is just out of date.

This old Apple document has additional description of USB audio, but its developer links have rotted.

Technical Note TN2274: USB Audio on the Mac

TN2274: details Apple's support for USB audio to help developers design class compliant devices that work seamlessly with the Mac.

developer.apple.com

Next step, look more carefully at Xcode support for Audio Plugins.