Installing driver for Mac audio via Distrobox?

Making an Intel Mac’s built-in audio work with Linux requires installation of a specific audio driver from this repo, which offers instructions for use with four distros — none of which is an OpenSUSE product, MicroOS/Aeon or otherwise. Two questions, then…

  1. Am I correct that this is Installation Situation #4 and, thus, there is no way to install the driver in MicroOS through a Distrobox?
  2. If that’s the case, would the four steps under that repo’s “Build driver” instructions all be done within sudo transactional-update shell? (I tried that earlier with no success, but it’s entirely possible I did it wrong.)

Correct, if you need a driver like that, it must be done through transactional-update, if you’re using Aeon or Kalpa, installing it through a distrobox will not work.

1 Like

@bwintx Hi and welcome to the Forum :smile:

Do you have a link to this requirement?

Sure you just need additional cirrus modules loaded related to the sound device?

Can you post the output from inxi -Axxz.

@malcolmlewis The link is GitHub - davidjo/snd_hda_macbookpro: Kernel audio driver for Macs with 8409 HDA chip + MAX98706/SSM3515 amps (as in my first post, above). The additional driver is for audio from a Mac’s built-in speakers or a non-USB headphone jack. I have already changed out the installation for Arch, due to my earlier lack of success in applying the driver via transactional-update, so this result from inxi -Axxz is from Arch rather than MicroOS/Aeon (if that matters), with the driver installed in Arch through the procedure on that link:

Audio:
  Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel
    v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170
  Device-2: AMD Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590]
    driver: snd_hda_intel v: kernel pcie: speed: 8 GT/s lanes: 16
    bus-ID: 01:00.1 chip-ID: 1002:aaf0
  API: ALSA v: k6.5.3-arch1-1 status: kernel-api
  Server-1: JACK v: 1.9.22 status: off
  Server-2: PipeWire v: 0.3.80 status: off
  Server-3: PulseAudio v: 16.1 status: active with: pulseaudio-alsa
    type: plugin

@bwintx The kernel module in question appears to be this one snd-hda-codec-cs8409 those patches are way out of date as appear to be for the 5.x.x kernel…

Really need to see the output from openSUSE as well as lsmod output.

If it does need patching then you would probably need to rebase the patches and just build as a kmp rpm to install, no need to rebuild the whole kernel…

This is also a hybrid system intel/AMD, what model Mac?

@malcolmlewis Thanks for the info. Perhaps I’ll try MicroOS again tomorrow and see what I can come up with — although I’m not nearly sufficiently adept to rebase patches or build RPMs. :smile:

The driver repo goes back several years and most of the commits are relatively old (plus, Apple began to phase out Intel Macs over the last couple of years), so your comment about the patch being outdated surely makes sense.

This is also a hybrid system intel/AMD, what model Mac?

Mid-2017 iMac (“iMac 18,3”).

@bwintx why not try a live USB of Tumbleweed instead, also TW/MicroOS use pipewire as the default…

I may just defer to using USB-connected or Bluetooth audio devices, since those seem to work without issues (Tumbleweed has the same problem, as do all other distros); it’s just the internal speakers and regular headphone jack that are problematic.

After seeing the video of Richard Brown’s talk from a few months ago, I’m really interested in MicroOS. :smile:

@bwintx well this device (8086:a170) is supported by the openSUSE MicroOS driver, so once you get thing up and running can have a look at building a kmp for you…

1 Like

@malcolmlewis I appreciate the offer! In the end, I simply went to the store and bought a nine-dollar USB-to-3.5" adapter and that took care of it. :smile: However, I was unable to install MicroOS on the Mac without issues similar to what was reported in this thread. Other distro installs, including Fedora Silverblue, have encountered no such issues despite the pre-installation drive erasure having been the same in all cases. :person_shrugging: