To be clear, AppleALCU doesn't do anything useful for my build, but unlike AppleALC (no U) it doesn't result in kernel_task burning cycles when I supply a layout ID.
As I explained in a much earlier post, I believe that interrupts get serviced through kernel_task, IOW interrupt handling is it's own process, which is a richer way of scheduling the work being driven by devices as they complete IO as compared to traditional Unix. For the lay person, my take means that kernel_task consolidates the kernel execution time belonging lots of different I/O activity driven by device interrupts.
CAVEAT EMPTOR: I MAY BE WRONG ABOVE. While searching for clues, I found the most common complaint about kernel_task buring CPU time is laptop owners with thermal overload, bad temp sensors, overheating, etc, where kernel_task efficiently squanders Intel CPU cycles to reduce load. Sort of /dev/null for process scheduler. Kernel_task gets busy when doing lots of IO too, like video, so this is why I think it's processification of device driver code.
What I found using spindump was audio DAC-related device entry points were using a lot of CPU time, and this got me to consider disabling AppleALC, whereupon the kernel_task went quiet on my otherwise idle system. The reason I saw a difference between booting from USB and booting from onboard was that the onboard OC had a layout-id configured in config.plist and the USB OC (which was otherwise the same as onboard) did not. This was a holdover from my earlier experiments looking for a suitable audio layout, where I do my testing from a thumb drive.
So my experience was a comedy of errors resulting from config that can never work right (AppleALC not "U" with USB audio) that I concocted from magical incantations I got from a recipe a Dortania that doesn't call out any distinction of USB audio from PCI audio. As to what the U version of AppleALC does: this is Config that I'm pretty sure no one here understands. I say "no one" because I have searched high-and-low for detailed explanations of AppleALC and USB audio and these seem to be orthoganal concerns. I grokked this conundrum from reading about how to add audio layouts and discovering that a key step in that book of spells requires looking up codec details that don't exist for USB audio. Imagine reading a guide that begins by saying boot Linux and dump this OS codec special file (HW nexus), but your kit doesn't have that special file but it has working Linux audio!
One thing I haven't tried yet is reading the AppleALC code. But as a seasoned systems programmer I already know there's only so far you can go towards understanding in reverse. A system must be understood to properly code it, while looking back into an unknown system through code can only provide clues which might assist understanding if you are already smart. I draw the line at these OC modules as black-boxes, because I'm not suited to being an OC module hacker and I may find after lots of effort looking backwards that I am still missing key understanding which only travels forward from the audio HW design.
So la-la-la
Hth
