オーディオ on Boot macOS

ASRock Z690 Steel Legendのオーディオを動かす

Wed, 01 Dec 2021 23:15:43 +0900

ASRock Z690 Steel Legendのオンボードオーディオが動きました。AppleALC.kextのGithubのページを見に行ったら、Z690用のパッチの当たったバージョンがありました。以下の記事の続きです。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

Kext Updaterから開発版を入手する

Kext類の公開前開発バージョンは、Kext Updaterからも入手できます。Kextmanagerを選んで、Nightly Buildsの項目を見ます。ここから入手可能な開発バージョンの中に、AppleALCがありました。

これでダウンロードしたところ1.6.7を入手できました。EFIにある1.6.6と差し替えます。ASRock Z690 Steel Legendに搭載されているコーデックはALC897です。このlayout-idは、12, 23, 66, 69のいずれかとのことです。

Supported codecs · acidanthera/AppleALC Wiki

大抵はどれでも動くのですが、やはり最初に試した12で動きました。

これで音が出るようになりました。

ASRock Z590マザーボード搭載ALC1220で音を出す (その2)

Sat, 10 Apr 2021 15:53:49 +0900

AppleALC.kextがバージョンアップされて、Z590に搭載されたALC1220のPCIIDをサポートしてくれるようになりました。そのおかげで、PCIIDを偽装しなくても、ASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようになりました。

Z590マザーボードのサウンド

前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。

ASRock Z590マザーボードでmacOSを起動する

またPCIIDを偽装してRealtek ALC1220から音が出るようにしました。

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

AppleALC.kextがそのうち対応してくれると期待していたのですが、v1.5.9になったAppleALC.kextの説明に、以下のように書いてありました。ありがたいです。

Added 500 Series (0xF0C8 Z590 + Intel 10 Gen) PCH HD Audio Controller
Added 500 Series (0x43C8 Z590 + Intel 11 Gen) PCH HD Audio Controller

実際、Hackintool.appなどで確認すると、第10世代CPUを搭載した状態でのPCIIDはF0C8でした。これを以前のチップセットのものに偽装していたのですが、この更新でその必要がなくなりました。実際、新しいAppleALC.kextに差し替えることで、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

が不要になり、config.plistでのDevicePropertiesでのdevice-idの記述も不要になりました。layout-idは引き続き1を使用しました。

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

Mon, 29 Mar 2021 19:57:47 +0900

（こちらは古い情報です。最新のAppleALC.kextを使うことで、ここで行った手順は不要になりました。こちらをご覧ください。2021/4/10）

ASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようにしました。Z490のマザーボードを最初に使った時と同様に、FakePCIID.kextを使いIDを偽装します。近い将来、Z490の時と同様に、AppleALC.kextとOpenCoreがZ590チップセットに対応すれば、このような工夫なしで動くようになるのではと期待しています。

Z590マザーボードのサウンド

前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。

ASRock Z590マザーボードでmacOSを起動する

この結果、有線と無線のネットワークが動いています。USBは未調整ですがキーボード、Bluetooth関係は動いてます。でもマザーボードに搭載されたサウンドチップであるRealtek ALC1220から音が出ていませんでした。今回は、このサウンドチップを動かします。

Realtek ALC1220は、300シリーズチップセットから搭載されているサウンドチップです。AppleALC.kextで長らくサポートされているので、互換性は高いと思っていました。でもZ590マザーボードでは、AppleALC.kextを入れるだけでは動きませんでした。

一方、一部のZ590マザーボードでは、新しいサウンドチップのRealtek ALC4080 が搭載されています。新しいので互換性が心配でしたが、実はALC4080はUSB接続で動いていて、USBオーディオとして機能するのでドライバの心配がいらないという報告がいくつか上がっています。オンボードサウンドのことだけを考えたら、ALC1220よりも、新しいALC4080が搭載されたマザボの方が面倒がなくて良いかもしれません。

PCIIDを偽装する

まずは、ALC1220がサポートするlayout-idをいくつか試してみましたが、音は出ませんでした。ALC1220の場合、使用できるlayout-idは、1, 2, 3, 5, 7, 11, 13, 15, 16, 21, 27, 28, 29, 30, 34だそうです。layout-idは多少違っていても大抵は音が出るので、全く動かない場合は、layout-idの問題ではないと思われます。

他の方法を検索しましたが、結局、以前、Z490マザーボードが出始めた時に使った方法が有効でした。サウンドチップのPCIIDを偽装する方法です。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

この方法に従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに以下を追加しました。PciRoot(0x0)/Pci(0x1F,0x3)はALC1220のデバイスパスです。これのdevice-idをA348に、layout-idを1にする設定です。

Z590マザーボードに搭載されたALC1220には、ベンダー：デバイスIDとして、8086:F0C8が割り当てられています。このIDが、現在のバージョンのOpenCore/AppleALCには登録されていないようで、Hackintool.appで調べると、Device Nameが???という表示になります。

そこで、上記の内容をconfig.plistに加えることで、このIDが8086:A348になります。このIDはCannon LakeのALC1220のdevice-idと同じ値なので、下記のようにCannon Lakeの名前が表示されるようになります。

以上の作業を行うことで、無事、オンボードサウンドが出るようになりました。

まとめ

Z590マザーボードのオンボードサウンドチップであるRealtek ALC1220から音が出るように設定しました。以前のZ490の時もそうでしたが、OpenCore/AppleALCがZ590搭載のALC 1220に対応してくれれば、この作業は不要になると期待しています。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

次の作業はUSBの15個制限の調整です。ぼちぼち対処していきます。

HomePod miniを使う

Sun, 29 Nov 2020 00:19:43 +0900

HomePod miniを使ってみました。macOSからはAirPlayのスピーカーとして使えます。またHome.appからアラームの設定ができます。HomeKitのホームハブとして使えるそうですが、そちらは試せてません。

HomePod mini

Amazon EchoやGoogle Homeに比べて、Appleのスマートスピーカは高価なHomePod無印が1機種だけしかなく、普及に力を入れているという様子がありませんでした。でもHomePod miniが出て、競争力が付いたと思います。Echoは、安いのでいくつか使用してますが、結構便利です。でもAppleのエコシステムで生きているので、カレンダーやメッセージにアクセスできなくて物足りなく思ってました。今回、手頃な価格でコンパクトなHomePod miniが出たので、ようやく試せました。

設定

箱から出して、電源に接続して、iPhoneを近づけると、iPhoneに設定画面が現れます。このあとは数個の選択肢を設定していくだけです。

この辺りは、iOSを所有している会社の製品だけあって、手間要らずです。自社のアプリをダウンロードさせたり、起動させたりする手間が不要なだけでも有利です。Wi-Fiなどの設定も、Amazon Echoに比べたら格段に容易でした。てっぺんのLEDの点滅をiPhoneで撮影して、デバイスをペアリングする手法もスマートです。その結果、Wi-FiもBluetoothもApple IDも全てが、気づかないうちに設定終了してました。逆に言うと、iPhoneが無いと使い始めることもできないデバイスです。

このあと、Z390 + 9900KにOpenCore 0.6.3 + Big Sur 11.0.1の構成のmacOSマシンから何ができるのか試しました。無線ユニットは、純正Macと同じBCM94360CDです。

Hackintoshのパーツ選び【その4：無線編】

HomePod miniとの通信でBluetoothなども使っているのかなと思ったのですが、以下で紹介するAirPlayもHome.appも有線LANだけで動きました。BluetoothとWi-Fiをoffにしても同様に動きます。

AirPlayスピーカー

まずはサウンドです。デフォルトの選択肢からオフィスを選んであったのですが、その名前でAirPlayデバイスとして見えてます。これを選択するだけで、すぐに音が出ました。Bluetoothのペアリングは、簡単そうで失敗することも多いのですが、こちらは手間要らず機能します。キーボードの音量キーも操作可能でした。HDMIやUSBオーディオだとキーボードの音量キーが効かないことも多いので、これは助かります。

すでに色々な人が音質が良いとレビューしてますが、評判通り、音質はそこそこ良いです。ステレオスピーカーと比較すると、HomePod miniはモノラルなので、広がりに欠けるのは仕方ないです。ちなみに、2台のHomePod miniを用意すると、iPhoneからはステレオになります。でもmacOSのAirPlayではモノラルのスピーカーが2個に増えただけになってしまうらしいです。macOSで使う限り、1台だけ買えば良いようです。

しばらく使ってみると、いくつか不具合に気づきました。まず、YouTubeで動画を止めたり動かしたりしていると、HomePod miniの設定音量とずれてしまうことがありました。また、macOS警告音の「サウンドエフェクトの再生装置」として、システム環境設定の選択肢にHomePod miniが現れることもあれば、現れないこともあります。バグのような感じなので、そのうち直してくれるかもしれません。

もう一点、気になったところは、遅延が大きい場合があることです。サウンドエフェクトの再生装置として現れる場合、通知音のサンプルをクリックしてから1~2秒くらい遅れて音が出ます。MusicやQuickTime Playerなどで音楽の再生・停止ボタンを押すと、2秒くらいしてから反応します。動画再生・停止でも遅延します。でも映像も遅延するので、音との同期がズレる現象はないのです。いずれの場合も、マザーボードのサウンドチップでは瞬時に応答するので、AirPlayが原因だと思われます。何処かのバッファメモリが一杯、または空っぽになるまで、操作結果が反映されない感じです。遠隔会議ではこの遅延のために対話が成り立ちません。いろいろ謎の遅延ですが、これもそのうち直してくれるのかもしれないです。

ホーム.app

ホーム.appを開いてみました。オフィスという場所に、HomePod miniが見えてました。名前は変更できます。いくつかの設定も変更できます。でもできることは、アラームを設定する程度の事でした。macOSから操作するよりも、Siriに音声でお願いしたほうが楽そうです。

純正環境との比較

AirPlayの遅延などに関しては、hackintosh環境なので、不具合が起こっても当然だったのかもしれません。それで純正Mac, iPhone環境ではどうなのかを確認しました。

純正Macとの比較

Big Sur 11.0.1が動いている本物のMacBookからこのHomePod miniに接続して確認しました。警告音のデバイスに現れない、2秒くらい遅延するという状況は、同様に発生しました。hackintoshの問題ではないようです。

iPhoneとの比較

iPhoneから接続すると、Musicアプリでも、一般のアプリ（例えばSafariで見るYoutubeサイトの動画）でも、遅延はありませんでした。

AirPlay 2.0

先の説明で、macOSのAirPlayではHomePodはステレオにならないと書きました。正確には、macOSでも、Music.appからだけはステレオになるそうです。

調べたところ、初代HomePodが発表された2017年に同時に、AirPlay 2.0が発表されて、そこで複数スピーカーの同期ストリーミングがサポートされたのだそうです。これにより2台のHomePodでのステレオ再生がサポートされたのだと思われます。この時に、遅延の問題も改善されたのでは無いかと思いました。それで、iOSは全面的にAirPlay 2.0に対応しているので、遅延が発生しないけど、macOSではMusic.appだけが2.0に対応しているので、Music.appを使う時だけは、ステレオにもなるし、遅延も発生しないということかと思いました。

実はmacOSのMusic.appでも、設定によっては2秒の遅延が発生します。純正Macでも同様です。Music.appのAirPlayアイコンから、HomePod miniを選択すると、遅延は発生しません。「オフィス」というのがHomePod miniです。

でもここで「コンピュータ」を選んで、macOSの「システム環境設定」「サウンド」からAirPlayデバイスを選ぶと遅延が発生します。前者は、

Music.app ---> ( AirPlay 2.0 ) ---> HomePod mini

という接続になっていて、ステレオになって遅延も発生しないけど、後者は、

Music.app ---> macOS ---> ( AirPlay ) ---> HomePod mini

というようにmacOSを経由した設定で、この場合、古いAirPlay無印が使用されて、その結果遅延が発生するということかと推測できます。macOSのMusic.appは自前でAirPlay 2.0を実装しているのか、それとも2.0を提供するmacOSの未公開APIがあってそれを使用しているのかと思われます。

まとめ

HomePod miniが自作マシンのmacOSから使えることを確認しました。AirPlay接続のスピーカーとして使えて、さらにホーム.appにはデバイスとして現れます。ただ遅延が大きいので、コンピュータ用スピーカーには向いてませんでした。常設のSiriデバイスとして使っていきます。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

Thu, 06 Aug 2020 21:56:56 +0900

OpenCore 0.6.0が出たので、ASUSのZ490マザーボードのオーディオを再設定しました。OpenCore 0.6.0とAppleALC.kext 1.5.1がZ490マザーボードに対応したことから、PCI IDを偽装しなくても動くようになりました。

今までの設定

前回は、OpenCore 0.5.9を使ってZ490マザーボード搭載コーデックを動かしました。特別な設定不要で音が出たASUSの先代Z390マザーボードには、ASUSの仕様書によると、オーディオユニットにはSupremeFX S1220という名前が付けられています。Hackintoolなどで調べるとコーデックはRealtekのALC1220のようです。Z490マザーボードになって、これがSupremeFX S1220Aになってました。HackintoolではRealtek ALCS1220Aになっています。SやAが追加されていますが数字部分は同じなのであまり変わらないと思ったのでしたが、デバイスIDを偽装する設定を行わないと、音が出ませんでした。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

ここに書きましたように、kextに、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を入れ、さらにconfig.plistでデバイスIDを指定し、レイアウトIDを7に指定する必要がありました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

OpenCoreとAppleALCの最新版を使う

OpenCoreが0.6.0になり、またAppleALC.kextが1.5.1になり、その両方の資料で、Z490マザーボード搭載オーディオに対応したとの記述を見つけました。ならば、FakePCIIDを使わなくても音が出るようになったのかと思い、試してみました。

まずはAppleALC.kextだけ更新しました。それでFakePCIID_Intel_HDMI_Audio.kextを外してみました。FakePCIID.kextは、Ethernetチップを動かすためにも必要なので、外してません。でも音は出ませんでした。そこでOpenCoreも0.6.0にアップデートしました。0.5.9から0.6.0へのアップデート作業は、こちらをご覧ください。

OpenCore 0.5.9 から 0.6.0 に更新

AppleALCとOpenCoreの両方をアップデートしたところ、FakePCIID_Intel_HDMI_Audio.kext無しで、config.plistにもデバイスIDを書かなくても、音が出ました。config.plistの該当部分は、こんな感じになりました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

レイアウトIDは必要です。このマザーボードは7でしたので、それがBase64形式で書いてあります。

まとめ

ということで、OpenCoreとAppleALCの現行バージョンなら、レイアウトIDの指定だけで、何も特別なことをしなくてもZ490の音が出るようになりました。コメントでもOpenCoreとAppleALCの最新版でPCIIDの偽装が不要になったとの情報をいただいています。新型iMacで第10世代CPUが採用されたこともあり、これでZ490がさらに気軽に使えるようになったと思います。

OpenCoreで起動音を鳴らす

Tue, 14 Jul 2020 21:40:03 +0900

OpenCoreでMacの起動音が出るようにしました。起動画面をGUI化した際にインストールしたリソースファイルに起動音のファイルも入っていました。これとAudioDxe.efiを用意し、config.plistに幾つかの設定をすることで、起動音が鳴りました。

今回は、こちらの記事の続きです。

OpenCoreの選択画面をグラフィカルにする

少し前のMacでは起動音が出ましたが、煩わしいので消している人も多かったです。でも、最近のMacでは復活するという噂もあります。そうなると、起動音があっても良いのかなと思い、OpenCoreで試してみることにしました。今回も以下のガイドに従っています。

制限

起動音は、macOSが起動する前に鳴らすので、macOSのドライバーは使えません。コミュニティの皆さんが頑張って作ってくれたドライバーで音を出します。なのでマザーボード上の音源チップからのみ音が出せます。つまり、以下の制限があります。

USBオーディオからは起動音を出せません。
GPUオーディオからは出せる場合もありますしダメな場合もあります。

実際のMacは電源を入れると即座に音が出ます。ファームウェアが音を出しているのでタイミングが早いです。でもHackintoshで起動音の出るタイミングは、電源を入れて、BIOSのスプラッシュ画面が出て、OpenCoreのメニュー選択画面になったところです。電源投入から少し待たされます。ここまで来て、制御がようやくOpenCoreに引き渡されるので、仕方がないところです。

設定手順

音声ファイルを用意する

メニューGUI化の時にアイコンファイルを入手したのと同様に、以下から音声ファイルを手に入れます。

GitHub - acidanthera/OcBinaryData

このうち、OCEFIAudio_VoiceOver_Boot.wavが起動音のファイルです。これをOC/Resources/Audioの中に入れておきます。

ドライバーを用意する

AudioDxe.efiをOC/Driversの中に入れておきます。AudioDxe.efiはOpenCoreの配布ファイルに含まれています。

config.plistを設定する

config.plistをProperTreeで開いて、設定作業を行います。まずはSnapshot機能でAudioDxe.efiを登録しておきます。次に以下の設定を行います。

NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> SystemAudioVolume を0x46にする。10進数では70です。
UEFI -> Audio -> AudioSupportをTrueにする
UEFI -> Audio -> MinimumVolumeを50にする
UEFI -> Audio -> PlayChimeをTrueにする
UEFI -> Audio -> VolumeAmplifierを143にする

数字のところはボリュームの設定なので適当で良いようです。ただ、適切な範囲や大小関係の制約はあるようです。

ここまではガイドの例に合わせて設定するだけなので簡単です。問題は、ハードウェアごとに調整しなければならない3個のパラメータです。UEFI -> AudioのAudioDevice、AudioCodec、AudioOutです。

AudioDeviceを設定する

PciRoot(0x0)/Pci(0x1f,0x3)に設定しました。オーディオチップに割り当てられたPCIeのパスを指定します。すでにconfig.plistのDevicePropertiesで、マザーボード搭載コーデックのレイアウト IDが指定してあれば、そこのPciRoot以下の数値です。下の例ならPciRoot(0x0)/Pci(0x1f,0x3)です。

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

HackintoolのPCIeボタンからAudio deviceを探して調べることもできます。

またgfxutilというツールを使っても良いです。これを起動すると出てくるHDEFの行に、チップのPCIeパスが書いてあります。

% ./gfxutil | grep HDEF
00:1f.3 8086:a348 /PCI0@0/HDEF@1F,3 = PciRoot(0x0)/Pci(0x1F,0x3)

AudioCodecを設定する

0に設定しました。オーディオチップのアドレスIOHDACodecAddressを設定します。これはioregコマンドやIORegistryExplorerなどで調べることができます。ガイドに従って、以下のようにioregコマンドをタイプしたところ、

% ioreg -rxn IOHDACodecDevice | grep IOHDACodecAddress
 | "IOHDACodecAddress" = 0x0
 | "IOHDACodecAddress" = 0x2

上のように、0番と2番の二つの選択肢がありました。ここでアドレスが1個しか出てこなければ、迷うことなくその数値（たぶん0です）をAudioCodecに書いておけば良いです。ちなみに0番と2番が出てきたマザーボードはASUS ROG MAXIMUS XI HERO Z390です。一方で、ASUS ROG STRIX Z490-Gのマシンでは、IOHDACodecAddressは一個（0番）だけでした。

今回は2個の候補が出てきてしまったので、このどちらかを指定します。どちらかが、マザーボードに搭載されているコーデックです。ちなみにこのマザーボードのコーデックはRealtek ALC1220です。いろいろ調べる方法はあるようですが、ここでは以下のようにしました。まずは、grepの条件を緩めて、前後の情報を表示しました。

% ioreg -rxn IOHDACodecDevice | grep IOHDACodec
+-o IOHDACodecDevice@1F,3,0 <class IOHDACodecDevice, id 0x10000059d, registered, matched, active, busy 0 (1024 ms), retain 27>
 | "IOHDACodecVendorID" = 0x10ec1220
 | "IOHDACodecRevisionID" = 0x100101
 | "IOHDACodecAddress" = 0x0
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a5, !registered, !matched, active, busy 0 (1022 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,0,1 <class IOHDACodecFunction, id 0x1000005a7, registered, matched, active, busy 0 (1022 ms), retain 27>
+-o IOHDACodecDevice@1F,3,2 <class IOHDACodecDevice, id 0x10000059e, registered, matched, active, busy 0 (138 ms), retain 27>
 | "IOHDACodecVendorID" = 0xffffffff8086280b
 | "IOHDACodecRevisionID" = 0x100000
 | "IOHDACodecAddress" = 0x2
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a6, !registered, !matched, active, busy 0 (135 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,2,1 <class IOHDACodecFunction, id 0x1000005a8, registered, matched, active, busy 0 (135 ms), retain 25>

これを見ると、下のIOHDACodecAddressが2番のもののVendorIDに8086という数値が見えます。これはインテル社のものです。一方で、0番には、VendorIDに10ecという数値が見えます。Vendor IDは世界的に決められている番号なので「vendor id 10ec」でGoogle検索すると、メーカの名前が分かります。これは、Realtek Semiconductor Co., Ltd.のIDだそうです。

PCI Devices

ということで、これがRealtekのチップらしいので、AudioCodecには0番を指定すれば良いようでした。

AudioOutを設定する

0に設定しました。こちらは苦労しました。この番号で、オーディオピンの番号を指定するようです。バックパネルにアナログ5本、SPDIFが1本、さらにはマザーボード上にケースのヘッドフォン端子に接続するオーディオ用ヘッダピンもあります。これのいずれかを番号で指定するようです。0番から順番に試すしかないようです。手元のマシンで0番を試したところ、それがバックパネルのスピーカ出力でした。

まとめ

OpenCoreで起動音を出せるように設定しました。ほとんどの作業は、バニラガイドに書いてある通りで簡単ですが、AudioDevice、AudioCodec、AudioOutの設定は、環境に合わせて変更する必要があります。特にAudioOutは手探りでした。起動音は、最後まで鳴る時もありますが、どういうわけか中途で音が出なくなることもあります。起動音がなると、さらに本物のMacっぽくなって良いのですが、ちょっと煩いかもしれません。しばらく楽しむけど、常用はしないと思います。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

Sun, 07 Jun 2020 16:27:15 +0900

前回紹介したASUSのZ490マザーボードで、動かなかったオンボードオーディオとEthernetが動きました。少しトリッキーな方式のような気がしますが、hackintoshコミュニティのサポートが充実するまでのつなぎとしては十分です。

追記：OpenCore 0.6.0とAppleALC.kext 1.5.1になり、オーディオはレイアウトID（このマザボは7）を指定するだけで動くようになりました。こちらをご覧ください。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

参考にしたページ

前回は、OopenCoreのComet Lake-S　バニラインストールガイドに従って、正攻法なインストールを行いました。そのためか、マザーボード搭載のオーディオコーデックと2.5 Gbps Ethernetが動きませんでした。

Comet Lake-S 10600とZ490でmacOSを動かす

OpenCoreのバニラガイドが出る前に、SchmockLoadさんがGIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていました。そこでは、オーディオも2.5 Gbps Ethernetも動いているようです。今回はこれを参考に作業しました。

GitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https…

オーディオを動かす

追記：オーディオに関するこの節の情報は古いです。こちらをご覧ください。

今回使用しているマザーボードに搭載されたコーデックはRealtek ALC1220です。もしかしたらALC1220Aなのかもしれません。ASUSはSupremeFX S1220Aと呼んでいます。300シリーズマザーボードでも搭載されていたコーデック（そちらはSupremeFX S1220無印）と数字部分は同じです。なので、AppleALC.kextで動くと思ったのですが、簡単には動きませんでした。

そこで、上記のSchmockLoadさんのGitHubガイドに従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>

（略）

 <key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
 <dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
 </dict>

を追加しました。FakePCIIDの仕組みはこちらで説明されてます。ちゃんと理解できていないのですが、PCIeのデバイスIDを、macOSのドライバが認識するIOPCIDeviceに結びつけてくれる機能のようです。本体がFakePCIID.kextで、デバイスIDの情報だけが書いてあるInfo.plistだけのkext（今回の場合はFakePCIID_Intel_HDMI_Audio.kext）と組み合わせて使います。これによりmacOSが認識しないIDのデバイスを動かしてしまおうという機能のようです。

FakePCIID_Intel_HDMI_Audio.kextは、その名前の通り、100, 200, 300シリーズのHDMIオーディを実現する目的で作られているようです。今回の場合に当てはまるのか疑問でした。説明を見ると、100シリーズ以降で0xA170もしくは0x9D70のデバイスIDを使えるようにしてくれるようです。ここでは0xA170を使っています。これを動かすためには、動かしたいオーディオデバイスの、ACPIに現れるデバイスIDを0xA170に変更しておく必要があります。それが上記のconfig.plistの記述です。

Hackintoolで確認してみます。オーディオチップはPci(0x1f,0x3)のPCIeデバイスパスに配線されています。そのデバイスIDは0x06C8でした。

上記のconfig.plistを使うと、このデバイスIDが0xA170に変更されていることがわかります。デバイス名も、100 Series/C230 Series Chipset Family HD Audio Controllerと表示されるようになっています。それでも実際のコーデック名とはちょっと違う気がしますが、これで音声が再生されるようになりました。

Z490マザーボードでのサウンドチップの変更は、おそらくはデバイスIDなどが多少変更された程度の違いと思いますので、そのうちにAppleALC.kextが対応してくれるのだと期待しています。それまではこの対応で凌げると思います。

Ethernetを動かす

このマザーボードに搭載されているEthernetチップは、2.5 GbpsのIntel I225-Vです。上位のマザーボードでLANが2個あるタイプのものは、もう片方が従来と同じ1 GbpsのIntel I219-Vだったりします。I219-Vは300シリーズでも使われたチップなので、IntelMausi.kexe, IntelMausiEthernet.kextで動くようです。でもi225-Vしか搭載されていないマザーボードは有線LANに接続できません。

こちらも、オーディオと同様に、FakePCIIDを使って解決できました。FakePCIID_Intel_I225-V.kextが設定をしてくれます。

FakePCIID.kext
FakePCIID_Intel_I225-V.kext

また同様にconfig.plistでEthernetチップのデバイスIDを0x15F2に設定します。ちなみにこのマザーボードでは、元々のデバイスIDは0x15F3でした。

	<key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>
	<dict>
		<key>device-id</key>
		<data>8hUAAA==</data>
	</dict>

SchmockLoadさんによるとFakePCIID_Intel_I225-V.kextを作ってこの設定を紹介したのはドイツのHackintosh-forum.deのBrumbaerさんだそうです。GitHubにあるconfig.plistの例では

 <key>PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)</key>

になっていますが、上記のHackintoolの一覧に現れているように、ASUSマザーボードではデバイスpathが違うようです。

 <key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>

を指定したところ動きました。これでネット接続できるようになりました。おそらくはIDを偽装して、macOS標準のドライバで動かしているのだと思われます。とはいえ、1Gbpsのハブに接続して使用したところでは、速度が遅いとか、データが滞るなどの問題は感じられませんでした。IntelMausi.kextが対応するまでのつなぎとして十分に使用できそうです。

Geekbench 5でベンチマーク

ネットに接続できるようになったので、Geekbenchで測定しました。Geekbenchは結果がweb上で表示されるので、ネット接続してないと起動できませんでした。結果は、以下のようにマルチコアスコアで6000越えでした。

現行の非BTO版最上位iMacは3.7 GHz 9600Kを搭載しています。は無印なので（K付きは未発売でした。今もかな？）クロックが遅い (3.3 GHz) です。でも9600Kでは無効にされたハイパースレッドが復活しています。互角の性能である気がしましたので、Geekbench Browserで9600K搭載iMacのスコアを検索してみました。

マルチコアスコアが5000を切ったスコアも、6000を超えたスコアもありましたが、大半が5000代でした。結局、クロックが10%くらい低下しても、ハイパースレッドが効いたのか、10600無印の方が高速のようです。

まとめ

10600搭載Z490マザーボードの自作マシンでマザーボード搭載のオーディオとEthernetが動きました。AppleALC.kextとIntelMausi.kextが対応してくれるまでのつなぎとして使えます。ネットが動いたのでGeekbench 5でベンチマークをしました。これに相当する性能と思われる9600K搭載のiMacより高いスコアが出ました。

HPの小型デスクトップELITEDESK (2: Audio設定)

Tue, 24 Mar 2020 00:10:51 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のオーディオを設定しました。config.plistでDevices->Audio->Injectを11に設定すれば良いです。搭載された内蔵スピーカーからも音が出ました。

前回、このマシンにmacOSをインストールして、動作確認とベンチマークをしました。実はここで紹介したconfig.plistではオーディオが動いていませんでした。この続編では、オーディオの設定を行います。

HPの小型デスクトップEliteDesk (1: macOS導入)

AppleALCの設定

マザーボード搭載オーディオを動かすための最も一般的な方法は、Lilu.kextと、オーディオ用プラグインであるAppleALC.kextを使う方法です。最初に、

この2個のフォルダをEFI/CLOVER/kexts/Otherに入れ、
config.plistで設定

すれば作業完了です。AppleALC.kextに関してはこちらの記事をご覧ください。

Liluとプラグイン：(2) AppleALCの使い方

これによると、config.plistのDevices->Propertiesでオーディオ設定する方法が推奨されています。でも古いやり方とされている、Devices->Audioで設定する方法の方が簡単です。将来のLiluでサポートされなくなるかもしれない方法らしいのですが、簡単な非推奨な方法を使いました。

前回の作業では、Devices->Audioで以下の設定を行いました。

<key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>ResetHDA</key>
 <true/>
 <key>Inject</key>
 <integer>1</integer>
 </dict>
 </dict>

Audioには二つのkeyを設定しています。最初のkeyはResetHDAで、これを有効にしています。これにより、macOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。macOSだけを使う場合には不要かもしれません。ちなみに、(オーディオ)コーデックとはcoder/decoderの略で、圧縮された(音)データを復号して(音の波形)データに戻したり、その逆を行うソフトウェアとか装置とかアルゴリズムのことです。そう言う機能を行うICチップを指すこともあります。ここではICチップのことです。

次のkeyのInjectではレイアウト番号と言う値を指定します。レイアウト番号は、今まで大体1番で動いていたので、とりあえず1番を設定しました。しかしこれでは音が出ませんでした。この他に、2,3,4,5,6あたりまで試してみたのですが、どれも音が出ません。手当たり次第に試しても先が長そうだったので、筐体の蓋を開けて、マザーボード搭載コーデックを特定することにしました。

コーデックはALC221

このマシンの蓋はネジ一つで開くので簡単です。マザーボードの上の2.5インチベイやCPUクーラを外さないとコーデックが見えないかと思ったところ、手前の端のなんとか見える場所にありました。前面パネルには、オーディオ用のミニジャックが2個あるのですが、その近くでした。2.5インチベイの金具がかぶさってますが、斜めから覗き込めました。おなじみの蟹マークのRealtekのチップで、ALC221でした。（追記：こちらのスペック表にもALC221と書いてありました）

それぞれのコーデックで使用すべきレイアウト番号の一覧は、こちらのサイトに掲載されています。これによると11または15を指定すべきようです。両方を試してみましたが、11が正しいようです。15では音が出ませんでした。と言うことで、config.plistのAudioの項目は、以下にします。

<key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>ResetHDA</key>
 <true/>
 <key>Inject</key>
 <integer>11</integer>
 </dict>
 </dict>

ヘッドフォンと内蔵スピーカ

前面パネルには、ヘッドフォンのマークが描かれたミニジャック端子（左側）と、ヘッドフォン＋マイクロフォンのマークが描かれたミニジャック端子（右側）の、合計2個のミニジャックがあります。後者（右側）はどう言う種類なのか不明でした。iPhoneのイヤフォン（イヤフォンとマイクロフォンが一体になっています）を挿してはみたのですが、どちらも使えませんでした。とはいえ、FaceTimeなどではUSB接続のwebカメラかスピーカーフォンを使い、アナログマイクロフォンを使うことはまず無いと思います。なのでこれ以上は調べませんでした。

使用できたのは、ヘッドフォンのマークが描かれた左側のミニジャック端子です。ここにミニプラグを挿し、アンプ付きスピーカに接続したところ、良い音で音楽を聴くことができました。システム環境設定のサウンド->出力の表示にも、名前：ヘッドフォン、種類：ヘッドフォンポートと表示されました。

左のジャックからプラグを抜くと、今度は内蔵スピーカーから音が出ます。3cmくらいの小型のスピーカーなので、電話の受話器のような音質・音量ですが、一所懸命頑張っている感じで可愛いです。サウンドの表示も、内蔵スピーカー、内蔵に自動的に切り替わります。

もう一つの出力項目である、ライン出力、オーディオライン出力ポートは、どこにあるのか所在不明でした。1世代前の、HP EliteDesk 800 G1 DMには、背面パネルにオーディオライン出力ジャックがありました。G2で背面オーディオ出力ジャックが無くなってしまったのが残念なのですが、あの名残がマザーボード上にあるのかもしれません。

一方、サウンド入力画面には、ライン入力、オーディオライン入力ポート、と言う項目が2個表示されています。この2個についても所在不明でした。前述の、前面パネルにあるヘッドフォン＋マイクロフォンの描かれたミニジャックかと思いましたが、ちょっと試した限りでは使えませんでした。

まとめ

HP EliteDesk 800 G2 DMのヘッドフォン端子と内蔵スピーカーから音を出すことができました。

自作PCに、ビープ音を鳴らすスピーカーをつける例は多いですが、コーデック接続のスピーカを内蔵する例はあまり見かけません。タワー型の筐体ならスペースはあるので、内蔵スピーカがあれば省スペースになって良い気がします。実際に、デスクトップMacにはどれもスピーカーが内蔵されてます。なので、メーカ製デスクトップPCで内蔵スピーカから音楽を出せたのが面白かったです。

Liluとプラグイン：(2) AppleALCの使い方

Sun, 01 Dec 2019 11:30:54 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAppleALCの使い方の部分の抄訳です。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenを紹介しました。

Liluとプラグイン：(1) WhateverGreenの使い方

AirportBrcmFixupに関しても後ほど紹介したいと思います。

（ここから抄訳）

AppleALCとは

AppleALCはLiluのプラグインです。ネイティブでないオーディオコーデックに対してHigh Definition Audio (HDA)を有効にするために、AppleHDA kextに動的にパッチを当てます。WhateverGreen (以下WEG) と同様に、オーディオを有効にするために従来使用していた多くのパッチとkextを置き換えてくれます。なのでAppleALCを使用する前には、既にあるAppleHDAを有効にするパッチ、ダミーのkext、DSDTへの変更などを取り除いておき、AppleHDAをオリジナルの状態のkextに戻しておく必要があります。

Nvidia HDMIオーディオ

AppleALCはほとんどのNvidia GPUでHDMIオーディオを有効にします。必要な作業は、LiluとAppleALCをインストールする事だけです。もしHDMIをサポートしたNvidiaカードが使われていたら、AppleALCはこれを検出して、HDMIオーディオコントローラを有効にします。サポートされたNvidiaデバイスはこちらのページを見てください。Nvidiaデバイスのこのリストの最後にあります。

オンボードオーディオコーデック

AppleALCは、Raltek (ALC)、Conexant、IDTなどの多くのビルトイン（オンボードの）オーディオコーデックをサポートします。大抵の場合、やるべきことは、LiluとAppleALCをインストールして、config.plistに簡単な変更を加えるだけです。が、その作業の前に、AppleALCがどのように機能するか知っておくと良いです。

AppleALCはどのように動くのか

AppleALCの動作は従来の、AppleHDAに予めパッチを当てたり、ダミーを使ったりする方法と少し違います。AppleALCはコネクター、レイアウト、プラットフォームパッチの大規模なデータベースと理解できます。ロードされる際に、LiluとAppleALCは使用されているオーディオコーデックのタイプを自動的に検出し、データベースからパッチを探して、AppleHDAに動的にパッチを当てます。

AppleALCが使うパッチは、インデックス識別子により定義されています。バックワード互換性のために、パッチセットのインデックス識別子はlayout-idと呼ばれるプロパティ値で定義されています。layout-idはhackintoshのコミュニティで昔から使われてきた値で、パッチを当てたバージョンのAppleHDA（もしくはダミーHDA kextの）のレイアウトを選択する値です。

AppleALCのwake verb

追加の機能として、AppleALCはほとんどのコーデックのwake verbの面倒を見てくれます。なので、Codec Commanderをインストールしたり使用する必要はありません。（訳注：コンピュータがスリープするとオーディオアンプもoffになります。スリープから目覚めるときに、アンプがonにならなくて、スリープ復帰後に音が出ない問題が発生する事があります。wake verbはスリープ復帰時にアンプをonにするための特別なデータのようです。これを流す事でアンプがonになるようです。〜という理解で正しいでしょうか？間違っているようでしたらコメントで指摘してください。）

LiluとAppleALCのインタラクション

（訳注：この節の内容は理解できませんでした。すみません）

Liluがロードされると、Liluはlayout-idの値を見つけて、その値をAppleALCに渡します。この値を継承して、AppleALCはalc-layout-idという名前の新しいデバイスプロパティを作ります。AppleALCは次に、layout-idの値を新しいターゲットID（通常は7）に設定し、AppleHDAのターゲットレイアウトに（Liluのパッチエンジンを使って）パッチします。この時、指定した（alc-layout-idで指定された）コーデックのための、コネクターID情報、infoファイル、プラットフォームファイルが使われます。

この方法により、AppleALCはMojaveのドロップドレイアウトIDを無視します。（詳細はこの記事のオーディオの節を見てください）。というのは、インジェクトされたlayout-id値は、AppleALCのコーデックパッチデータベースのインデックスとしてのみ使われるからです。AppleALCはこのlayout-idによる再マップする枠組みを、Mojaveだけでなく、全てのバージョンのmacOSで使います。

サポートされているコーデックを確認

使用しようとしているコーデックをAppleALCがサポートしているかどうかは、ソースコードのResoucesフォルダの中で名前を探せば確認できます。コーデックがサポートされていなかったら、公式のAppleALCヘルプスレッドに投稿して、次のバージョンで入れてもらうよう依頼してください。そのコーデックの詳細（このスレッドの#1投稿を見てください）を投稿します。達人の誰かが、その投稿を見て、手助けを申し出てくれるでしょう。おそらく、Linuxを使ってコーデックのダンプを用意する必要があります。このガイドの対象外の話題なので、ここでは詳細に関して説明しませんが、あなたの投稿を見た誰かがダンプの取り方を説明するリンクを示してくれるはずです。

もし、使用しようとしているコーデックが、既にAppleALCでサポートされていたら、どのレイヤーがサポートされているかを、対応するコーデックフォルダにある、info.plistファイルを開いて知ることができます。これから、どのレイヤーIDが使用可能なのかがわかり、また、コメントからそのうちのどれを使うべきかを知ることができます。

一例として、私の2017年版HP Spectre X360ラップトップの場合は、Realtek ALC295コーデックを搭載しています。そこで、ALC295フォルダの中のinfo.plistを開きます。以下に示します。

ALC295 の info.plist（tonymacx86.com の画像）

この例では、Mironeさんのパッチが必要なパッチであり、これがレイアウト3であることがわかります。このように、コメントを読めば、システムに必要なレイアウトの記述を簡単に見つけられます。もし、全ての使用可能なレイアウトID値のリストが不明な場合、一つ一つ試して動く値を探します。また、Hackintoolを使ってどのレイアウトがサポートされているのか（下の方法で詳細を説明します）知ることもできます。

AppleALCの設定

AppleALC.kextをインストールした後ですべきことは、layout-idを設定することです。2つの方法があります。

方法1：Audio Injectで設定する（古い方法）

Liluはconfig.plist内のレガシーなパラメータであるClover/Device/Audio/Injectからlayout-id値をCloverに問い合わせる機能があります。なのでInjectのString値を正しいlayout IDに設定すれば良いです。以下のようにします。

<key>Devices</key>
<dict>
 <key>Audio</key>
 <dict>
 <key>AFGLowPowerState</key>
 <true/>
 <key>Inject</key>
 <string>3</string>
 <key>ResetHDA</key>
 <true/>
 </dict>

LiluがClover/Devices/Audio/Injectからlayout-idを取得するというレガシーな方法をサポートしなくなる可能性があることは注意すべきです。なので、次に示す方法2が良いです。

方法2：Device Propertiesを使う（おすすめ）

AppleALCとLiluをインストールした後、config.plistを編集して、Devices/Audio/Injectを”No”にします。そしてLayout-idをカスタムDevice Propertyとして設定します。ここで、Audio Device Propertyコードを作成するために、Hackintoolを使います。HackintoolのAudioアイコンをクリックすると、検出されたコーデックタイプが表示されます。ここで設定したいHDAオーディオデバイスを選びます。するとAudio Infoに詳細な情報が出て、ドロップメニューでLayoutを選べるようになります。ドロップメニューには検出されたコーデックに適用可能なlayout IDのみが表示されます。

項目選択が終了したらPatchアイコンを押し、Patch機能を呼び出します。もしオーディオデバイスがシステム情報のPCIデバイスセクションの中で正しい名前で表示させたかったら、Advanced optionsの中のSpoof Audioオプションを選択します。この時Advancedページの他の項目は全てチェックを外します。

次に、Generalをクリックして、Device / PropertiesとAudio Deviceオプション以外のチェックを全部外して、Generate Patchをクリックします。

ここに現れたコードを、config.plistの該当する部分にコピーペーストします。以下のようになります。（訳注：Z390チップセット搭載マザボのALC1220を対象に同じ操作をしたのですが、心当たりのないmodel名になっていたり、hda-gfxという項目があったりしました。model名は適当に編集して、hda-gfxの項目は削除して良いのだと思います。）

 <key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict> 

 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>AAPL,slot-name</key>
 <string>Internal</string>
 <key>device-id</key>
 <data>
 cKEAAA==
 </data>
 <key>device_type</key>
 <string>Audio device</string>
 <key>layout-id</key>
 <data>
 AwAAAA==
 </data>
 <key>model</key>
 <string>Sunrise Point-LP HD Audio</string>
 </dict>

 </dict>
 </dict>

config.plistの変更が完了したら、再起動してオーディオが動いているかどうかテストします。もし動いていなければ、他の有効なlayout-IDを試してください。

もし、全ての有効な値を試してもオーディオがまだ動かない場合は、新しいパッチセットが必要なコーデックを使っているのかもしれません。サポートされていないコーデックに関しては、AppleALCのヘルプスレッドを利用してください。

AppleALCのトラブル対策

AppleALCがロードされていることを確認する

AppleALCが正しくロードされて初期化されていることは、IORegisteryExplorerで確認できます。これはこちらのリンクからダウンロードできます。

IORegisteryExplorerを動かして、HDEFという文字を検索ボックスに入れます。ioregディレクトリーツリーにHDEFデバイスが見えるはずです。上の例では、次のように見えます。

HDEFが見えないようでしたら、LiluとAppleALCのインストール手順を確認してください。以下のACPI HDA/Codec Rename 問題も見てください。

上のスクリーンショットでは、AppleALCが動的に新しいプロパティalc-layout-idを作り出している事がわかります。ここでの3という値は、config.plistで設定した値です。同様に、layout-idという項目は7とあります。これは、AppleALCがパッチを当てようとしている対象のAppleHDAでのレイアウトで、macOSが使っているものです。

もし、HDEFの中にalc-layout-idが見つからない場合、AppleALCが正しくロードされていない、もしくは初期化されていないのかもしれません。この原因は、kextが正しくインストールされていないからです。kextを削除して、インストールを再度試みてください。

HPET 問題 (High Precision Event Timer)

上記のステップが正常でもなお音が出ない場合、HPETによってIRQの衝突が発生している可能性があります。

macOSにおいて、HPETは基本的に必要な仕組みです。これが正しく働く必要があります。このフォーラム（訳注：tonymacx86のフォーラム）のほとんどのガイドでは、BIOSでHPETを有効に設定していることを前提としています。しかしながら、いくつかのマザーボードとラップトップでは、HPETに関するネイティブなDSDTコードがIRQ衝突を引き起こし、AppleHDAの正しい初期化を妨げたり、雑音を出す事があります。

この問題を確認する一つの方法は、ターミナルで次のコマンドを入力する事です。

kextstat | grep 'Lilu\|AppleALC\|AppleHDA'

この結果、Lilu, AppleALC, AppleHDA kextがリストアップされるはずです。

MonkeyPro-2018:~ Jay$ kextstat | grep 'Lilu\|AppleALC\|AppleHDA'
 20 4 0xffffff7f81041000 0x22000 0x22000 as.vit9696.Lilu (1.2.8) 54014689-C8DA-318B-84F4-944BBA7AD2AC <8 6 5 3 2 1>
 23 0 0xffffff7f811bd000 0xdf000 0xdf000 as.vit9696.AppleALC (1.3.3) B60FCBAF-6BC2-36EF-A1E6-D5BE2863C35B <20 13 8 6 5 3 2 1>
 138 1 0xffffff7f830a7000 0x1d000 0x1d000 com.apple.driver.AppleHDAController (282.10) 70256EC9-AF38-31BD-A3C5-9C0E30B64AA3 <137 113 107 13 8 7 6 5 3 1>
 157 0 0xffffff7f8323a000 0xb7000 0xb7000 com.apple.driver.AppleHDA (282.10) B2208DA8-8CD9-36D8-BD59-C6D9A5379585 <156 138 137 124 113 107 7 6 5 3 1>
 159 0 0xffffff7f830c6000 0x2000 0x2000 com.apple.driver.AppleHDAHardwareConfigDriver (282.10) C4F674A0-5828-3D97-82BF-A81C8B8BDDBA <5 3>

この例から分かるように、AppleHDA、AppleHDAController、 AppleHDAHardwareConfigDriverとインストールされています。ここで重要なのは、 AppleHDAです。

もしAppleHDA (com.apple.driver.AppleHDA)が出力に現れていなかったら、HPETオプションが正しく有効になっているかどうかを確認してください。もし有効になっていてもAppleHDAが現れなければ、DSDTのHPETコードにパッチを当てる必要があります。

これを行う最も簡単な方法は、CloverのACPI/DSDT/Fixesの中の FixHPETをtrueにする事です。

<key>ACPI</key>
<dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>

この方法はほとんどのユーザで有効です。でも、もしCloverのHPETフィックスでもまだAppleHDAがロードされない場合、DSDTに直接パッチを当てる必要があるかもしれないです。RehabManさんがこのパッチを作ってくれていて、MaciASLを使って適用できます。

#Maintained by: RehabMan
# HPET fix to avoid AppleIntelCPUPowerManagement panic
into method label _STA parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 code_regex Name\s\(_STA\,\s+0x0F\) remove_matched;
into device name_hid PNP0103 insert
begin
Name (_STA, 0x0F)\n
end;

into method label _CRS parent_hid PNP0103 remove_entry;
into device name_hid PNP0103 insert
begin
Method (_CRS, 0, NotSerialized)\n
{\n
 Return (BUF0)\n
}\n
end;

このパッチをDSDTに当てるためには、MaciASLを使い、Patchボタンを押し、上記のコードをパッチエディターにコピーペーストします。そしてApplyボタンをクリックして、DSDTを保存します。詳しい情報は、Rehabmanさんのガイドを見てください。また、DSDTにパッチを当てた場合は、Cloverのfixは無効にしておきましょう。

ACPI HDA/Codec 改名問題

WhateverGreenと同様に、 AppleALCとLiluはDSDTの中のACPIの名称を適切に自動的に改名してくれます。しかし時々失敗することもあり、手作業で改名する必要があります。この改名が正しく実施されているかどうかは、IORegistryExplorerを開いて、HDEFを検索してみればわかります。

もしHDEFがioregに存在すれば、これ以上の作業は不要です。しかし、もし存在していなければ、ここまで述べた作業が正しく行われているかどうかを確認してください。それでも解決しなければ、HDEF名称変更を手作業で行ってみる必要があります。

まずは、バニラな状態のDSDTをMaciASLで開いて、HDEFで検索して、元々のHDAデバイスの名前を確認します。もし検索結果がなければ、HDASで検索します。それがなければAZALで検索します。

もしHDAデバイスがHDEFと名付けられていたら、デバイスを改名する必要はありません。もしHDASと呼ばれていたら、次のコードをconfig.plistのACPI/Patchesに追加します。

<dict>
 <key>Comment</key>
 <string>change HDAS to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 SERBUw==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

もしAZALでしたら、以下のパッチを追加します。

<dict>
 <key>Comment</key>
 <string>change AZAL to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 QVpBTA==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

CORPNEWTさんのバニラガイド~ Clover設定とkext

Sat, 26 Jan 2019 17:01:20 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Cloverの設定」と「kextを集める」のページをご紹介します。Hackintoshで使うカーネル拡張(kext)ファイルを簡潔に説明しています。

Page not found

（ここから抄訳）

Cloverをインストールする

Cloverインストーラパッケージを起動します。インストーラの2番目のページで、インストール先（USBメモリとかSSD/HDD）を選択するよう気をつけます。また、デフォルト設定はイマイチなので、カスタマイズします。（訳注：図は私が用意したスクリーンショットです）

左下のカスタマイズボタンを押すとカスタムインストールのページが出ます。ここで、以下を選択します。

「UEFIブート用にインストール」
「ESPにインストール」
Drivers64UEFIの中の設定（訳注：現在バージョンではUEFI Drivers）
- AptioMemoryFix: VRAM に関する修正を含んだ新版です。より良いメモリ管理をします。
- VBoxHfs-64.efi: 入手できれば HFSPlus.efiでも良いです。CloverがHFS+起動ボリュームにアクセスするために必要です。HFS+で起動したいのに、起動オプションに現れないようなら、 EFI -> CLOVER -> drivers64UEFI フォルダにこれが入っていることを確認すると良いです。
- ApfsDriverLoader: Didsさんの Cloverビルドもしくはこちらから入手可能です。これはCloverがAPFS起動ボリュームにアクセスするために必要なapfs.efiを、ブロックデバイスのApfsContainerからロードします。もしAptioMemoryFixを使用しているなら、R21以降が必要です。（訳注：現在バージョンでは最新版が入っているので項目を選択するだけです）

以上です。

もしもFileVaultが不要で、標準的なUEFIインストールをするだけなら、これらが必要なものの全てです。これ以外のものも、Drivers64UEFIセクションに現れます。しかし、選択しなくても良いです。むしろ他の設定と衝突する項目（例えば SMCHelper-64.efi ）すらあります。なのでDrivers64UEFIセクションでの選択は最小限にするのが良いです。

（訳注：最近のCloverインストーラではFileVault関係のefiはFileVault 2 UEFI Driversという別のセクションに分類されました。FileVaultを使わなければ、多分誰も使わないと思いますが、これは全部除外して良いです。このガイドでは3個のefiしか必要ないと書かれていますが、ハードウェアによってはこれ以外が必須のこともあります。EmuVariableUefiが必要だったり、AptioMemoryFixの代わりにOsxAptioFixDrvが必要だったりします。）

Kextをコピーする

Cloverのインストールが終了したら、/Volumes/EFI/EFI/CLOVER/kexts/Otherに移動して「kextを集める」で用意したkextをここにコピーします。 .dSYMファイルは不要です。.kextだけが必要です。

/Volumes/EFI/EFI/CLOVER/kextsフォルダの中には、Otherフォルダと、10.xxフォルダがあります。この違いは以下です。Cloverがkextをインジェクトしようとするとき、10.xxフォルダのkextは、macOSのバージョンが合致している時だけインジェクトされます。ところがmacOSのバージョンに依存するkextはほとんどありません。また、macOSをアップデートした時にそのバージョン番号のフォルダを用意することを忘れてしまうと、起動できなくなってしまいます。Otherフォルダのkextは、検出されたmacOSバージョン番号とは関係なくインジェクトされます。なのでOtherフォルダを使うことをお勧めします。

必要なkextはどれ？

VirtualSMC.kextは必須です。これはMacに搭載されているSMC (System Management Controller) チップをエミュレートしてくれます。これによりOSは本当のMacだと思い込みます。これなしではHackintoshできません。

以下のすべてのkextはGoldfish64さんにより整備されたこちらのサイトで入手可能です。それぞれのkextは更新されると自動的にビルドされます。自分でビルドしたかったら私のLilu And Friendsのスクリプトを使用してください。

Ethernet関係

IntelMausiEthernet.kext – これはほとんどのIntel LANチップで動きます。
AppleIntelE1000e.kext – これは古いIntel LAN チップで動きますが、新しいチップではカーネルパニックすることもあります。
AtherosE2200Ethernet.kext – これはほとんどのAtheros または Killer のチップで動きます。
RealtekRTL8111.kext – これはほとんどのギガビットRealtek LAN チップで動きます。
RealtekRTL8100.kext – これは10/100bps Realtek LAN チップで動きます。

USB関係

多分 USBInjectAll.kextが必要です。もし、H370, B360, H310のCoffee Lake system、またはX79/X99/X299を使うなら、XHCI-unsupported.kextも必要になると思います。

10.11からアップルはUSBコントローラごとに15個のポート数制限をしています。大した問題ではないと思われるかもしれませんが、USB 3ポートは2個（USB 3として1個、USB 2として1個で合計2個）としてカウントされますので、この制限には割と簡単に到達してしまいます。

Skylake以降では、USB 2とUSB 3はXHCIとしてのみ扱われて、それぞれのUSB 3が2個としてカウントされ、すぐに制限に達します。USB 2をEHCIに割り当てることで改善する方法もあります。これにはRehabManさんの FakePCIID.kext + FakePCIID_XHCIMux.kext を使います。これによりXHCIの負担を軽減します（ただし一部のチップセットでしか機能しません）。

Audio関係

マザーボードのAudioチップがサポートされたコーデックであるなら、/u/vit9696さんの AppleALC.kext と、これと一緒に使う Lilu.kext が必要です。AppleALCはAppleHDA.kextに動的にパッチ当てし、macOSのオーディオでサポートされていないコーデックを動かす機能があります。スリープ復帰後のオーディオ機能を手助けする機能もあります。

Graphics関係

GPUのためには、WhateverGreen.kextと、支援kextである Lilu.kextを使うべきです。これは、以前は別々のkextであった、IntelGraphicsFixup, NvidiaGraphicsFixup, CoreDisplayFixup, Shikiの機能を合わせ持っています。

WiFi と Bluetooth関係

Appleは最低限のWiFiチップしかサポートしていません。そこで、2つのチップセットだけを紹介します。私は、PCIeアダプタに取り付けたBCM94360CDと、BCM94352HMB / BCM94352Z だけを使っています。BCM94360CDはOOBでバニラなままで動きます。BCM94352風味の場合では、 WiFi設定のためにAirportBrcmFixup.kextと Lilu.kextを使い、さらに、BrcmBluetoothInjector.kext (10.13.6以降の場合) または BrcmPatchRAM2.kext を、 BrcmFirmwareData.kext と一緒に使います。すべてのBrcm* kextsという名前のkextは、RehabManさんの OS-X-BrcmPatchRAM から入手可能です。

その他

使用するハードウェアに応じて、これ以外のkextも必要になるかもしれません。でもこのガイドは一般的で基礎的な内容を目指したので、あとはGoogleで検索してください。

HackintoshでSiriを使う

Sun, 25 Mar 2018 00:30:00 +0900

macOS Sierraから音声アシスタントのSiriが使えるようになっています。HackintoshでもSiriを使うことができます。ただ、一体型のMacにはSiriに適したマイクロフォンが内蔵されていますが、自作PCで作ったHackintoshでは別途用意する必要があります。

マザーボード搭載のオーディオチップが使えるように設定してあれば、マザーボードのジャックにアナログマイクロフォンを接続すれば使えます。でも、Webカメラ内蔵のマイクロフォンを使うのが安価、高性能で簡単だと思います。Webカメラがあれば、FaceTimeやSkypeやそのほかのテレビ電話・会議システムで使えます。USB接続のWebカメラなら、Hackintoshでも特別なドライバのインストールなしで、画像入力・音声入力をそのまま使用することができます。Webカメラは多数販売されています。例えばLogicoolのC270は、HD 720pですがテレビ電話・会議に十分な画質で価格も安いです。マイクロフォンも優秀です。LogicoolのWebカメラを接続すると、内蔵マイクロフォンが、「システム環境設定」の「サウンド」「入力」にUnknown USB Audio Deviceとして表示されていますので、これを選択します。

iPhoneなどで使用するBluetoothイヤフォンの多くにも、通話のためのマイクロフォンが内蔵されています。これもHackintoshのSiriで使用することができます。Bluetooth接続すると、「システム環境設定」「サウンド」「入力」にBluetoothに分類される入力装置が現れるのでこれを選択します。

入力装置の設定が終わったら、「コマンドキー」「スペースキー」の長押しで、Siriが応答します。色々試してみましょう。なお、macOS High Sierraからは、「システム環境設定」「アクセシビリティ」「Siri」から「”Siriにタイプ入力”を有効にする」項目が用意されていて、これをチェックすると音声だけでなくテキスト入力によりSiri利用が可能になります。

Alexaも使ってみる

AppleのスマートスピーカHomePodが米国などで発売されていますが、日本はまだです。Siriベースで、Macとの親和性の高いHomePodは楽しみです。一方、スマートスピーカとしては、GoogleのGoogle HomeとAmazonのAmazon Echoがすでに先行しています。

Amazon Echoの音声アシスタントであるAlexaもmacOSで使うことができます。App Storeで配布されている以下のアプリケーションをインストールするだけで利用できます。Siriと同様に、HackintoshでもWebカメラやBluetoothイヤフォンのマイクを使ってアクセスできます。

Reverb for Amazon Alexa

Rain
仕事効率化
無料

アプリケーションが起動すると、EchoのLEDのようなリングが表示されて、これを長押ししている間、音声認識します。

Amazon Echoを使えば、Amazonのサービスで使えるコンテンツにアクセスできるのですが、残念ながらこのプログラムは音楽再生に対応していません。でもニュースなどを再生してくれます。また、iCloudとも連携できるので、カレンダー.appで管理しているスケジュールも教えてくれます。Amazon Echoで制御できる照明器具やスイッチなどが販売されていますが、このアプリケーションを使うと、HackintoshからEcho対応照明をon/offすることもできました。

OK Googleも使えるはず

Google Homeの音声アシスタントもmacOSで使えるようです。以下の記事に詳しく書かれています（この関連記事でmacOS用Alexaのことも知りました）。

news.mynavi.jp

ただ、設定が大変な上に英語にしか対応していないようです。また、Googleのエコシステムを前提としているので、iCloudのカレンダーを利用することはできません。ということでこちらは試していません。macOSにはGoogle HomeよりもAmazon Echoの方が親和性が高いようです。

パッチを当てるkext: Lilu.kext

Sat, 23 Sep 2017 23:09:00 +0900

Lilu.kextはkext (カーネル拡張)にパッチを当てる仕組みを提供するkextです。ライブラリやプログラムにもパッチを当てられるようですが、kextにパッチを当てるために便利に用いられています。今年になってから登場した新しいkextです。元々は、サウンドを提供するkextであるAppleALC.kextを開発していた人が、パッチ当ての部分を分離して公開してくれたものです。なので、現在のAppleALC.kextもLilu.kextを使っています。

Releases · acidanthera/Lilu

Lilu.kextはパッチを当てるkextと一緒に使います。バニラな構成ならば、それぞれをEFI/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。Cloverもconfig.plistのKextsToPatchセクションの記述でkextにパッチを当ててくれます。この記述は簡単なのですが、kext本体のバイナリーファイルにしかパッチを当てられません。Lilu.kextは、パッチ方法を指定するkextを開発する必要がありますが、kext本体以外の様々なファイルや設定にパッチを当てられるようです。

以下で、Lilu.kextと一緒に使うためのkextを紹介します。

AppleALC

macOSのHD audio機能を使って音を出すためのパッチ。こちらで説明しました。

/posts/120/

古いバージョンは単独で動きますが、パッチ当て機能をLilu.kextに分離した後のバージョンは、Lilu.kextと一緒に使います。

Releases · acidanthera/AppleALC

WhateverGreen

~~10.12.6からRX480/580などのAMDグラフィックスカードがサポートされました。しかし、メインディスプレイにはならず、起動時にはCPU内蔵GPUなどの補助GPUが必要でした。これを解決するのがWhateverGreen.kextです。Radeonを使う人には必須です。~~以前はAMDグラフィックスカードの不具合に対応するkextでした。それでAMDカラーのgreenという名前が付いています。今は、

IntelGraphicsFixup
NvidiaGraphicsFixup
Shiki

の機能を統合し、ディスプレイに関係するパッチ機能をすべて盛り込んだkextになりました。詳しくは以下をご覧ください。これを入れれば統合されてしまったkextは使う必要がありません。

NvidiaGraphicsFixup

このkextはWhateverGreenに統合されました。

NVIDIAのGPUをiMac15,1 iMac17,1 MacPro 6,1のシステム設定で使おうとすると、ブート後に画面が黒くなって起動しなかったり、画面がスリープしたりする問題が発生します。 WebドライバだけでなくmacOS標準のドライバでも発生します。 iMacのレティナディスプレイやProのデュアルグラフィックスカードハードウェアを前提とした macOSの設定が、この問題を引き起こしているようで、black screen問題と呼ばれています。このkextを使うと、black screenを回避できます。

Releases · lvs1974/NvidiaGraphicsFixup

IntelGraphicsFixup

このkextはWhateverGreenに統合されました。

~~Intel HD Graphicsを使う場合に発生する以下の不具合を解決します。~~

~~Intel Graphics HD4000以降のブートロゴ表示の乱れ~~
~~Intel Azul Graphics (HD4400, HD4600)におけるPAVPフリーズ問題~~

ブートロゴの乱れは、起動時のアップルロゴとプログレスバーが表示される場面の後半で、表示が8個に分裂してストライプ状になる現象です。起動時だけのことで、無視しても良いくらいの問題ですがこれが解決されます。もう一つのPAVPフリーズ問題はもっと深刻で、一部の動画サイトをSafariで閲覧する場合や、iTunesでiTunes Storeの予告編を見る場面で、動画再生が滞ったり、場合によってはOSがフリーズする問題です。

Releases · lvs1974/IntelGraphicsFixup

Shiki

このkextはWhateverGreenに統合されました。

iTunesにあるDRM保護されているビデオはivy bridge以降で再生できない問題があります。購入した映画や、その予告編を再生しようとすると、映像が出ないとか、音だけしか出ない状態です。これを回避します。

Releases · acidanthera/Shiki

NightShiftUnlocker

10.12.4から導入されたNight Shift機能ですが、これにはMacBookPro9,x iMac13,x Macmini6,x MacBookAir5,x MacPro6,x MacBook8,x以降の機種が対応しています。これより古い機種でNight Shiftを動かすためのkextです。

Releases · 0xFireWolf/NightShiftUnlocker

そのほか

用途・効果を理解できていないのですが、Lilu.kextのサイトによると、このほかにも以下のようないろいろなパッチがあるようです。

AirportBrcmFixup Broadcom Airport Wi-Fi cardsへのパッチ

AzulPatcher4600 Intel HD 4600 へのパッチ

CoreDisplayFixup 非Iris Intel graphicsの高解像度サポート

CPUFriend 動的なパワーマネージメント

EnableLidWake ラップトップで蓋を開けた時のIntel Graphicsスリープ解除対応

HibernationFixup 3モードと25モードのハイバネーション対応

音を出す

Wed, 20 Sep 2017 20:05:42 +0900

Hackintoshで音を出すためのアプローチは、いくつかありますが、ここでは、一般的で簡単な3つの方法を難易度の低い順に紹介します。それぞれの作業量は、

何もしない
kextを1個入れる
kextを2個入れてconfig.plistを1項目追加する

です。

USBオーディオを使う

マザーボード搭載のオーディオチップを利用せずに、外付けの音源でデジタルアナログ変換するアプローチです。USB接続のDAC (デジタルアナログ変換器)を搭載した、スピーカ、アンプ、アダプターなどを接続するだけです。USBの標準的なオーディオ再生プロファイルを使うので、OSレベルでサポートされています。なので、特別のドライバーは不要で、何の手を加えなくても、音が出ます。ちなみに、Bluetoothスピーカも同様な仕組みで音が出ますので実機と同様に動きます。

USBオーディオ製品には、USBポート直結の安いDACがあります。手軽に試せて、実現できます。いくつか購入しましたが、どれもHackintoshで問題なく使用できました。ただスリープ復帰時にボツッというポップノイズが出る製品もありました。手元の環境でたまたま調子の良かったのは、この1,000円未満の製品でした。

USB DAC内蔵スピーカーも各種あります。これもいくつか購入しましたが、中でもこちらの製品は価格の割に良い音でした。

さらに手軽な値段のDAC内蔵アンプも多数あります。これをちゃんとしたスピーカに接続したらかなり良いオーディオ環境を実現できます。ピュアオーディオマニアが使うようなもっともっと高価な機器も使えます。

VoodooHDA.kextを使う

VoodooHDA.kextは、AppleのオーディオドライバであるAppleHDA.kextを置き換えることを目的に開発されているオープンソースのオーディオドライバです。これ単体で機能するドライバで、設定などがほとんど不要で、自動的にオーディオチップを検出してくれてすぐに機能します。一時は、クラッシュを引き起こすとか、音質が悪いとか言われていましたが、最近使ったところでは安定しているし、気になるような音質の問題もありませんでした。JeffさんのビデオでもVoodooHDA.kextを使っています。

**追記：**とあるマシンでVooDooHDA.kextを使っていると音割れがひどいことに気づきました。調整をしてくれるアプリケーションなどもあるので、それで頑張ると良いのかもしれません。でも次節で紹介するAppleALC.kextに替えたら音割れは起きなくなりました。VooDooは簡単ですが環境によっては合わない場合があるようです。(2018/6)

/posts/121/

VoodooHDA.kextをダウンロードして、ESPにあるCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。これだけで機能します。ESPに入れることでmacOSをバニラなままに保てます。

AppleALC.kextとLilu.kextを使う

3番目の方法は、昔から行われている伝統的な方法で、AppleHDA.kextに何とかオーディオチップを認識させようという方法です。そのために、AppleHDA.kextにパッチを当てたり、config.plistに必要な設定を書き込んだり、インジェクターkextを作ったり、こういう作業を自動化してくれるシェルスクリプトを走らせたり、など色々な手法があります。

このアプローチを格段に簡単にしてくれるのがAppleALC.kextです。これは、AppleHDA.kextにパッチを当ててくれるkextです。この開発者が、最近パッチを当てる機能を分離して、Lilu.kextという拡張機能を作りました。現在のバージョンのAppleALC.kextはLilu.kextと一緒に使います。この両方のkextをCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。AppleHDA.kextにパッチを当てないので、macOSをバニラなまま保つことができます。

こちらにAppleALC.kextがサポートしているチップ一覧があります。最近のマザーボードで一般的なRealtek以外に、Creative, CirrusLogic, AnalogDevices, Conexant, IDT, VIA, Intelをサポートしています。 IntelはHDグラフィックスのHDMI出力をサポートしています。

github.com

ここに書いてあるどのlayoutを使うかをconfig.plistに記載する必要があります。 Realtekの場合、だいたいは1で良いようです。以下に例を示します。

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