AppleHDA Audio, Configurer l'audio sur un Hackintosh

[Sebinouse]

AppleHDA Audio

Configurer l'audio sur un Hackintosh

Voici la méthode la plus simple pour faire marcher l'audio sur votre Hack après avoir suivi le Tuto de Chris27.

Cette méthode marche pour de très nombreux codecs et parfois pour l'audio HDMI.

ATTENTION : cette méthode part du principe que vous n'avez JAMAIS rien modifié ni ajouté pour faire marcher l'audio (script CloverALC de Toleda, realtekALC.kext, HDA enabler kext, aDummyHDA.kext, patchs Mirone, patchs AppleHDA en perl ou par Clover… ). Si vous avez fait la moindre modification : supprimez TOUS les fichiers ajoutés et restaurez le AppleHDA.kext d'origine ! Par ailleurs, elle ne fonctionne pas si vous utilisez VoodooHDA.kext et/ou AppleHDADisabler.kext.

Si votre AppleHDA.kext n'est pas un original, vous devrez consulter Restaurer un AppleHDA.kext original pour y remédier.

◉ Sommaire :

■ 1. Outils
■ 2. Recherches Préliminaires
■ 3. Injection
■ 4. Installation
■ 5. Customisation

◉ 1. Outils :

■ DPCIManager
■ AppleALC.kext
■ Lilu.kext

NB : Depuis la version 1.1.0 d'AppleALC.kext, Lilu.kext est obligatoire. AppleALC.kext ne fonctionnera pas sans lui !

◉ 2. Recherches Préliminaires :

■ Ouvrez DCPIManager et recherchez le Codec ID :

NB : Si DPCIManager n'affiche rien dans Codec ID et/ou Codec Name, regardez plutôt les spécifications de votre carte-mère sur le site du constructeur ou faites une recherche sur Google. En général, cette information s'y trouve.


■ Dans mon cas :

○ 0x10EC0283 Realtek

○ 10EC : VendorID de Realtek

○ 0283 : DeviceID de l'ALC283

Consultez cette page pour savoir si le vôtre est supporté et notez le "Layout" correspondant (il faudra peut-être en essayer plusieurs, un par un).

Dans mon cas, ce sera le layout 3 ou 11.

Si votre codec n'est pas encore supporté, il faudra passer par la case Customisation .

◉ 3. Injection :

L'injection se fait par le config.plist OU par une SSDT-HDEF.aml. Mais en aucun cas par les deux !

■ Méthode 1 via le config.plist (la plus simple):

Ouvrez votre config.plist avec le programme de votre choix, et ajoutez le boot-arg suivant :

○ Boot > Arguments > alcid=layout-id (où layout-id est le numéro du layout que vous avez choisi)

Ou

○ Devices > Audio > Inject=x (où x est le numéro du layout que vous avez choisi)

Par ex. (avec le layout 3) :

En XML, ça donne un truc du style (avec le layout 3) :

Boot Arguments :

Code

    <key>Boot</key>
    <dict>
        <key>Arguments</key>
        <string>alcid=3</string>
    </dict>

Devices :

Code

    <key>Devices</key>
    <dict>
        <key>Audio</key>
        <dict>
            <key>Inject</key>
            <integer>3</integer>
        </dict>
    </dict>

■ Méthode 2 via une SSDT-HDEF.aml (pour les plus expérimentés) :

Créez un ficher SSDT-HDEF.aml du style (là aussi avec le Layout 3 comme exemple) :

Code

DefinitionBlock ("", "SSDT", 1, "hack", "hack", 0x00003000)
{
    Method (_SB.PCI0.HDEF._DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
    {
        If (LEqual (Arg2, Zero))
        {
            Return (Buffer (One)
            {
                 0x03                                          
            })
        }

        Return (Package (0x0C)
        {
            "layout-id",
            Buffer (0x04)
            {
                 0x03, 0x00, 0x00, 0x00                        
            },

            "PinConfigurations",
            Buffer (Zero){},
            "AAPL,slot-name",
            "Built In",
            "name",
            "Audio Controller",
            "model",
            Buffer (0x20)
            {
                "Realtek ALC283 Audio Controller"
            },

            "device_type",
            Buffer (0x11)
            {
                "Audio Controller"
            }
        })
    }
}

Attention ! Cette fois le layout est en hexadécimal et pas en décimal : utiliser la calculatrice d'OS X en mode Programmeur pour les conversions (retenir que 1=0x01 ...9=0x09, 10=0x0A, 11=0x0B ... 15=0x0F, 16=0x10 ...)

Copiez ce fichier dans le dossier /EFI/CLOVER/ACPI/patched/ de votre partition EFI.

◉ 4. Installation :

C'est extrêmement simple :

■ copiez les fichiers AppleALC.kext et Lilu.kext dans le dossier/EFI/CLOVER/kexts/Other/ de votre partition EFI.

■ Redémarrez

Ce message a été modifié par polyzargone - 20 Dec 2021, 01:48.

Raison de l'édition : Ajout du lien vers le tuto Restaurer un AppleHDA.kext original

Fichier(s) joint(s)

 SSDT_HDEF_ALC283.aml.zip ( 764 octets ) Nombre de téléchargements : 71
 morceau_de_config.plist.zip ( 1.5 Ko ) Nombre de téléchargements : 93

 

[deneb]

Juste une dernière question: j'aimerais savoir ce qu'un boot Clover laisse en mémoire permanente dans la carte mère. J'ai le souvenir que la NVRAM sur un mac se situait dans un bout de mémoire flash, qu'on pouvait réinitialiser avec command-P-R. Mais comment ça se passe dans un hackintosh?
Question liée: comment est-il possible qu'un boot sur un disque externe puisse perturber un hack déjà existant sur un disque interne ? C'est ce qui s'est passé pour moi: après avoir tenté de démarrer sur une installation de Big Sur (opencore) ça a flingué mon Mojave interne (mais ceci dit mon disque avait quelques erreurs difficiles à réparer avec util de disque).
Enfin maintenant ça marche, merci pour le truc F11/F12 !

[polyzargone]

Juste une dernière question: j'aimerais savoir ce qu'un boot Clover laisse en mémoire permanente dans la carte mère. J'ai le souvenir que la NVRAM sur un mac se situait dans un bout de mémoire flash, qu'on pouvait réinitialiser avec command-P-R. Mais comment ça se passe dans un hackintosh?

En gros, de la même façon. Des informations (disque de démarrage, valeurs du SIP, arguments de boot et d'autres choses) sont stockées dans une mémoire qui ne s'efface pas même si le PC/Mac est hors tension.

Tu peux taper la commande suivante dans le terminal pour voir le contenu actuel de la NVRAM :

Code

nvram -xp

Question liée: comment est-il possible qu'un boot sur un disque externe puisse perturber un hack déjà existant sur un disque interne ? C'est ce qui s'est passé pour moi: après avoir tenté de démarrer sur une installation de Big Sur (opencore) ça a flingué mon Mojave interne (mais ceci dit mon disque avait quelques erreurs difficiles à réparer avec util de disque).

Clover et OpenCore ne stockent pas les mêmes choses en NVRAM suivant le paramétrage du config.plist. Si tu as des arguments de boot spécifiques sur l'un, ils risquent d'entrer en conflit avec ceux de l'autre. C'est pour ça qu'il est conseillé de faire un reset NVRAM quand on passe de l'un à l'autre ou quand on met à jour le bootloader (c'est surtout vrai pour OpenCore en fait).