AirPlay非対応のmacOSをレシーバーに変えてiOSから接続してやった
これはAirPlayが使えない哀れなMacをAirPlayサーバー化して、iPhoneやiPadから接続する記事です。
私はMac mini 2018と10.5インチiPad Proを使っています。
普段はiPadで動画や音楽を聴きながら作業することが多いのですが、このたびヘッドセットのマイクが故障したっぽいのでコンデンサマイクに新調することを決め、初めてオーディオインターフェース（MOTU M2）を買いました。
マイクとオーディオインターフェース併せて4万円くらいの出費です。
このMOTU M2はバスパワーとなっていて、Type-CのUSB端子が付いています。
PCに繋ぐとサウンドデバイスとして認識され、Macの音声をUSBケーブルで送ることができるわけです。
MOTU M2に接続したコンデンサマイクでPCにマイク入力しつつ、音声はヘッドホンで聴く感じですね。
Mac miniとはUSBケーブルで接続しています
これの直前に長らく愛用していたヘッドホン（Aurvana Live）が完全に壊れたのでATH-M40xというヘッドホンを買っていて「あんま変わらんなぁ……Aurvana Liveはコスパめっちゃ良かったみたいだしこんなもんか」と思っていたんですが、MOTU M2経由でPCから音楽を聴いたんです。
ここで音質の良さに感動しました。
オーディオインターフェースのDACってすげぇ！！
ってなってiPadからも接続して音楽を聴きたいなぁと思ったんですね。
これが長い旅の始まりでした。
だってよ……Mac mini 2018……AirPlayが！！！
ほぼ愚痴なので興味がない方は「UxPlayの環境構築」まで飛ばしてください。
iOSにはAirPlayという機能があって、iPhoneやiPadの画面や音声をMacに送ることができます。
スマホやタブレットの画面をPCに共有出来たり、PCをスピーカー替わりにできたりするわけですね。
似たようなことができるBluetoothは音質が劣化するのですが、AirPlay対応のスピーカーで聴く場合（※）、AirPlayはALACという圧縮方式で伝送するので音質が劣化しないという代物です。
※画面共有した場合はAACになります。ALACとAACのどちらで伝送するかはiOS側が勝手に決めるのでなぜかAACになることもあるらしい
HomePodみたいなスピーカー機器やApple TVもAirPlayに対応していたりします。
そういうAirPlayの受信側をAirPlayレシーバーと呼びます。
iPadの音声をオーディオインターフェース経由のヘッドホンで聴くのが今回のゴールです。
そして私の環境ではMacの音声の出力先がオーディオインターフェースになっています。
つまりAirPlayでゴールじゃん！！
「そういえばだいぶ前にAirPlayしたなぁ」と思ってMacの設定画面を開いて「AirPlay」で検索しました。
なんか左に「AirPlay レシーバー」の項目だけは見えるんですよね。「AirPlayオーディオストリーミング」という文字列も見えますが、これを選択してもAirPlay関連の項目はありませんでした。使えないなら無駄に希望を持たせるんじゃねえ！！！ 消せ消せ消せ消せ消せ消せ
なんか設定する箇所が消えてるんだが？？？？
AirPlayはmacOS Monterey 12.0で追加されたので、私も少し使ったことがあったはずなんです。
しかし今の私はmacOS Sonoma 14.3.1。
調べたところ、どうやら12.3で削除されていたのでした。
そう、Mac mini 2018だけがね。
AppleのページからAirPlayの機能要件を調べました。
iOS 14以降
- iPhone 7 以降
- iPad Pro (第 2 世代) 以降
- iPad (第 6 世代) 以降
- iPad Air (第 3 世代) 以降
- iPad mini (第 5 世代) 以降
macOS Monterey 以降
- MacBook (2018 年以降に発売されたモデル)
- MacBook Pro (2018 年以降に発売されたモデル)
- MacBook Air (2018 年以降に発売されたモデル)
- Mac mini (2020 年以降に発売されたモデル)
- iMac (2019 年以降に発売されたモデル)
- iMac Pro
- Mac Pro (2019 年以降に発売されたモデル)
- Mac Studio (2022 年以降に発売されたモデル)
はい。
つまり12.0でAirPlayに対応したが、Mac mini 2018においてAirPlayを使えたのは不具合だったので12.3で修正したということです。
そんなことある？
上記の通り、同じ年に発売された他のMacはできます。
あと「iPad Pro (第 2 世代)」は私が所有する「10.5インチiPad Pro」を含みます。
AirPlay対応のiPad Pro (第 2 世代)は2017年6月発売、AirPlay未対応のMac mini 2018は2018年11月発売ということで、先出しの製品の機能に後出しの製品が対応していないということです。
あとなぜかMac mini 2018でもSidecarというiPadの画面をMacのサブディスプレイにする機能は使えます。
似たような技術なのになぜなのでしょうか。
そっか……Appleってこういう企業だったな……と思ってBluetoothを使おうとしたら、macOS MontereyからiOSとmacOSはペアリングできなくなったみたいです。
これも前はできたんですけどね。
つまりmacOSはiOSのBluetoothスピーカーにはなれません。
別にいいもん……Bluetoothは非可逆圧縮のエンコード/デコードが発生して音質劣化するし……
納得できねえ……そんな煮えたぎる思いを抑えるためになんか理由があるんだろうと思って調べました。
macOSを解析している開発者のブログ（英語）にAirPlayできなくなった理由が考察されていました。
明らかに技術的な要因ではないと述べられていました。
Why did Apple only support these models?
Adding AirPlay to Mac (and Sidecar) support for older models | Mykola’s blog
At first glance, this limitation seems to be based off the T2 however upon closer inspection we see this is incorrect. Specifically iMac19,1 has no T2 and ships with a basic Polaris 20 dGPU core, then there’s the 2018 Mac mini with identical specs to the 2018 MacBook Pro 13”. Clearly the decision for which models were supported was not technical.
Appleが言いたいことが俺にはわかる。
要するにIntelじゃなくてApple Silicon搭載のMac買ってね♥ ってことだよね。
キレた。絶対にAirPlayしてやる。
ここで完全に目的と手段が入れ替わりました。
これはそんな物語です。
UxPlayの環境構築
UxPlayというOSSがあって、これをMacにインストールするとAirPlayできるようになります。
UxPlayは完全に独立したプログラムで、UNIX/LinuxやWindowsでも動くのでMacでも動くという理屈です。
（簡単に言ってますがマルチプラットフォーム対応ということです。すごいことです）
試した環境
- Mac mini 2018（macOS Sonoma 14.3.1）
- 10.5インチiPad Pro（iPadOS 17.3.1）
違う環境でも大丈夫だと思いますが、念のため。
UxPlayのインストールには色々必要なので、それらをインストールするところから始まります。
macOS側でターミナルの操作が必要なので注意してください。（慣れていない方は頑張ってください）
もし以下の手順通りにできなかったら、GitHubのページを見てみてください。
英語ですが結構情報を書いてくれてます。
XCode Command Line Toolsのインストール
まずはXCodeのコマンドラインツールをインストールしてください。
インストールされているかどうか確認するために、ターミナルを開いて下記を実行してください。
xcode-select -p私の環境では「/Applications/Xcode.app/Contents/Developer」という文字列が出力されました。
ここで「command not found」というメッセージが出てきたら、MacのApp Storeを開いて「XCode」をインストールする必要があるんですよ。
XCodeは容量がバカみたいにデカくてインストールにクソ時間かかります。
なのでXCodeはインストールせずに下記を実行してコマンドラインツールだけをインストールしてください。
sudo xcode-select --installインストールし終わったらまた「xcode-select -p」を実行してください。
なんか出てくるはずです。
ちなみにXCodeはアプリ開発（App Storeにアプリをリリースするために必須）のための開発者向けツールです。
いつもXCodeのバージョンアップがある時は寝る前にインストールを開始してます。マジで。
何やってるか知らんけど永遠に終わらないんですよね。僕が言いたいのは永遠
使うとしても私はVSCodeを選ぶので滅多に使わないんですが、私はAppleに屈しないエンジニアです。
そう、私はXCodeをインストール済み。バーカバーカ！！！！うんこちんちん！！！！
Homebrewのインストール
HomebrewかMacPortsのどちらかを使ってインストールできるのですが、ここではHomebrewを使います。
まずはHomebrewがインストールされているか確認してください。
brew -v私の環境だと「-bash: brew: command not found」になりました。
つまりインストールされていないので、Homebrewをインストールしていきます。
Homebrewの公式トップページに表示されているコマンドを実行してください。
2024年3月時点だと下記でした。たぶんほとんど変わらないと思いますが、念のため。
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"パスワードを入力してRETURN（ENTER）を押すとインストールが始まります。
インストールには十数秒～数分間くらいかかりますので待ちましょう。
XCodeの利用規約に同意しないとインストールできない件
XCodeを起動して利用規約に同意＝Agreeボタンを押していないとインストールできません。
同意していない方は先にXCodeを起動してください。
コマンドラインツールだけをインストールした方は上記画面を開けないと思います。
その場合は下記を実行して同意してください。
sudo xcodebuild -licenseSpaceかEnterキーを何回か押して、最後に「agree」と入力してください。
その後にもう1度実行すればインストールできるはずです。
Homebrewのインストールが終わったら、きちんとインストールされたか確認します。
brew -vHomebrewのバージョン情報が出力されればOKです。（私がインストールした時はHomebrew 4.2.10でした）
GStreamerのインストール
brewコマンドが使えるようになったので早速インストールしていきましょう。
まずはCMake 3.13以降、libplist、OpenSSL 3も必要になるので、先にこれらをインストールします。
brew install cmake
brew install libplist openssl@3上記のインストールが終わったらGStreamerをインストールします。
これは時間が掛かるのでしばらく待ちましょう。（ネット環境とマシンの性能によりますが5～10分くらい？）
brew install pkg-config gstreamerインストールが終わったらGStreamerが使えるようになったか確認します。
gst-launch-1.0 --versionこのコマンドを実行した時、私の環境だとしばらく固まった後に.cacheフォルダへのアクセスを許可するかしないかを伺うダイアログが出てきました。
「許可」を選ぶと下記のバージョン情報が出力されました。
gst-launch-1.0 version 1.22.10
GStreamer 1.22.10
https://github.com/Homebrew/homebrew-coreこれでGStreamerはインストールは完了です。
UxPlayのインストール
ようやくメインのインストールです。あと一息。
下記ページからソースコード一式をダウンロードしてください。
ダウンロードしたら自動で展開されます。
Finderを使って「ダウンロード」にある「UxPlay-master」を「アプリケーション」に移動します。
※もちろんターミナル上で「mv ~/Downloads/UxPlay-master/ /Applications/」してもOKです
移動したらターミナル上でcdしてUxPlay-masterディレクトリに移動し、ビルドしてインストールします。
cd /Applications/UxPlay-master/
cmake . ; make ; sudo make install特にエラーなくインストールできれば完了です。
そのまま下記を実行すると、UxPlayがオーディオ専用モード（画面なしのヘッドレス）で起動します。
/Applications/UxPlay-master/uxplay -vs 0起動すると下記のメッセージが表示されます。
UxPlay 1.68: An Open-Source AirPlay mirroring and audio-streaming server.
macOS detected: use -nc option as workaround for GStreamer problem
video_disabled
using system MAC address 【PCのMACアドレス】
Initialized server socket(s)この状態になるとiOSからMacがAirPlay対象として見えるようになります。
試しにYouTubeを開いて動画を再生してください。
右上のAirPlayのアイコン（右から3番目）をタップすると「UxPlay@～」が表示されると思います。
それを選ぶとAirPlayが始まります。
ですが、私の環境だと「接続できません」という表記が出てエラーとなってしまいました。
ファイアウォールを無効にしていたり、サードパーティのファイアウォールを使っている場合はこうはならないかもしれません。
私の場合はUxPlayが開いているポートでの通信ができていなかった（内部的にOperation timed outになっていた模様）ようで、Macのファイアウォールが通信をブロックしていることが原因であることが分かったので、ファイアウォールの設定からUnPlayを許可するように設定しました。
同じ症状に陥った方は設定から[ネットワーク]-[ファイアウォール]のオプションボタンを押してください。
下記の画面が出るので、ダイアログ左下の「+」からUxPlay-master内の「uxplay」を選んでください。
これでもう1度接続してみてください。
接続に成功しました！！
接続後、UxPlayが動いているターミナルでも下記のようなメッセージが出力されたと思います。
Accepted IPv4 client on socket 14
Local: 【MacのIPアドレス】
Remote: 【iOS端末のIPアドレス】
connection request from 【Appleのアカウント名】 (iPad7,3) with deviceID = 【iOS端末のMACアドレス】
Client identified as User-Agent: AirPlay/755.3.1
Accepted IPv4 client on socket 17
Local: 【MacのIPアドレス】
Remote: 【iOS端末のIPアドレス】
ct=2 spf=352 usingScreen=0 isMedia=1 audioFormat=0x40000
start audio connection, format ALAC 44100/16/2
raop_rtp starting audio
==============Audio Metadata=============ここで「start audio connection, format ALAC 44100/16/2」と出力されていることを確認しましょう。
AirPlayにはALACとAACで転送するモードがあり、ALACは音質が劣化しません。
これはiOS側が勝手に選んでいるようなのですが、少なくともUxPlayをオーディオ専用モードで起動した場合はALACで転送するようです。一応AACになっていないか確認しておきたいですね。
ちょっと残念なところとしては16bit/44.1kHz固定っぽいところでしょうか？
これはAirPlayの仕様でしょうし、CD品質には達しているので個人的には全く気になりません。
これでiPadで動画を再生してPCから（私の場合はヘッドホンから）音が出れば完了です！
ちなみにターミナル上でCtrl+Cを押すとAirPlayレシーバーが停止します。
様子がおかしくなったりしたらCtrl+Cしてもう1度起動し直しましょう。
音声が映像よりも早く再生されてしまう
私の環境だとなぜか音声が動画の内容よりもかなり早く再生されてしまいました。
そのままだとAirPlayのサーバーの音声とクライアントの映像がズレてしまうようで、ドキュメントを見てみたら「uxplay -asyncで起動してみろ」的なことが書いてました。
For Audio-only mode (Apple Music, etc.) best quality is obtained with the option "uxplay -async", but there is then a 2 second latency imposed by iOS.
https://github.com/FDH2/UxPlay
なんか「iOSによる2秒のレイテンシが課せられる」とか書いてありますね？
とりあえずこれは一旦置いておきましょう。
asyncオプションの説明もドキュメントに書いてあるので引用します。
In Audio-only mode the GStreamer "sync=false" mode (not using timestamps) is still the default, but if you want to keep the audio playing on the server synchronized with the video showing on the client, use the
https://github.com/FDH2/UxPlay-asynctimestamp-based option. (An example might be if you want to follow the Apple Music lyrics on the client while listening to superior sound on the UxPlay server).
こちらは「オーディオ専用モードの場合は映像と音声の同期を取るためにasyncオプションを付ける必要がある」ということが書いています。ということでやってみましょう。
私の環境では下記で直りました。
/Applications/UxPlay-master/uxplay -vs 0 -asyncただし-asyncには代償があって、iOS側の操作レスポンスが悪くなってしまいます。
具体的にはYouTubeの再生ボタン/停止ボタンを押して反映されるまでに2秒のラグが発生します。
This delays the video on the client to match audio on the server, so leads to a slight delay before a pause or track-change initiated on the client takes effect on the audio played by the server.
https://github.com/FDH2/UxPlay
これが前述で述べていた「iOSによる2秒のレイテンシが課せられる」の正体なのでしょう。
asyncオプション導入には紆余曲折あったようで、GitHubのIssueで熱い議論が交わされていました。
(Windows issues, some now fixed): Is it possible to set a buffer/delay? · Issue #169 · FDH2/UxPlay
気になる方は気になるでしょうね。
動画ズレと操作レスポンスの悪さ、どちらかを妥協する必要があります。この辺はお好みで。
-async 5を指定すると音声に対して動画を0.005秒遅延させて再生するようです。
基本的に数値指定なしの-asyncのままでいいと思いますが、もし音声よりも動画の方が早く再生されてしまうことがあれば試してみてもいいかもしれません。
AirPlayミラーリング（画面共有）のやり方
AirPlayは画面共有もできます。もしかすると検索で辿りついた方はこっちが目的かもしれませんね。
試しに-vs 0を付けずに起動してみましょう。
/Applications/UxPlay-master/uxplay次はiOS側のコントロールセンターで「画面ミラーリング」を選択するとUxPlayが出てきます。
それを選びましょう。
するとMac側で画面が立ち上がり、iOSの画面が共有されるようになります。
UxPlayのターミナルに出力されたログを見ると音声はALACではなくAACになっていますね。
UxPlay 1.68: An Open-Source AirPlay mirroring and audio-streaming server.
macOS detected: use -nc option as workaround for GStreamer problem
using system MAC address 【MacのMACアドレス】
Initialized server socket(s)
Accepted IPv4 client on socket 15
Local: 【MacのIPアドレス】
Remote: 【iOS端末のIPアドレス】
connection request from 【Appleのアカウント名】 (iPad7,3) with deviceID =【iOS端末のMACアドレス】
Client identified as User-Agent: AirPlay/755.3.1
Accepted IPv4 client on socket 24
Local: 【MacのIPアドレス】
Remote: 【iOS端末のIPアドレス】
raop_rtp_mirror starting mirroring
Begin streaming to GStreamer video pipeline
ct=8 spf=480 usingScreen=1 isMedia=1 audioFormat=0x1000000
start audio connection, format AAC-ELD 44100/2
raop_rtp starting audio標準だと30fpsなので割とカクカクしてますが、fpsオプションでフレームレートを変えることができます。
音声の遅延も大きいもののvsyncオプションで数値を指定すると多少マシになります。
/Applications/UxPlay-master/uxplay -fps 60 -vsync 1さすがに音ゲー配信は厳しいですが、ゲーム側の設定（判定調整）でやりようはあるかもしれません。
Deemoにはキー音という音ゲーならではのシステムがありますが、キー音をオフにしないと設定での調整は無理です
このウィンドウをDiscordで共有したりOBSで配信したりすることもできます。
UxPlayを使うとパラメータを自分で制御した上でAirPlayできるのが良いですね。
コマンドを毎回打ちたくないので.commandにしてDockに置く
UxPlayを起動する時に毎回ターミナルを立ち上げてコマンドを打つのが面倒だったので、DockのアイコンをクリックするとターミナルとともにUxPlayが起動するようにします。
まずは.commandファイルを作成してviで開きます。
cd /Applications/UxPlay-master/
touch UxPlay.command
chmod 755 UxPlay.command
vi UxPlay.commandviで開いたら下記を書き込みましょう。
UxPlayのオプションを変えている場合は自分用のものに変更してください。
#!/bin/bash
/Applications/UxPlay-master/uxplay -vs 0 -async編集が終わったら保存して閉じます。
viの操作方法が分からない場合（クリックして開く）
viコマンドを打った後に「a」を入力してみてください。
普通に編集できるようになります。
保存する時は下記の順番でキーを入力するものと理解してください。
（:wqも順番に入力してください）
- Escキー
- :wq
- Enterキー
保存したらFinderを開いて「UxPlay-master」に移動します。
UxPlay.commandを右クリックして「情報を見る」を選び、アイコンを適当なものに変えます。
アイコンはhttps://developer.apple.com/airplay/から拝借しました。
上記ページ内のアイコン画像を右クリックして「画像をコピー」を選んで、上の情報画面で左上のアイコンを選択してCtrl+Vで貼り付けると変えることができます。
変更したらそのままDockにドラッグ＆ドロップしましょう。
私のDockは縦にしているので下記のようになりました。
注意点としては、ゴミ箱が置いてある側のDockにドラッグ＆ドロップしなければいけない点です。
※アプリではなくただの.commandファイルだからです
あとはクリックして、ターミナルとUxPlayが起動するか確認してください。
起動すればOKです！
あとは快適なAirPlay生活を謳歌しましょう！！
私の復讐の物語はここで終わりです。お疲れさまでした。
UxPlayを使った感想
本来使用できないものを使用できているので、マジで足を向けて寝れません。
私がやりたいことも100%できています。
ただYouTubeで再生停止ボタンを押しても反応しないなど、たまに挙動がおかしくなることがあります。
そういう時は1度動画を閉じたり再接続したりすれば直ります。
iPadがロック（≒画面消灯の状態）されると不具合を引き起こしやすい印象です。
しかしながら何の脈略も無しに不具合を引き起こす感じではないので使用感はとても良いです。
飲み物を取りに行ったりトイレに立ったりする時が億劫になるかもしれませんが、許容範囲です。
あと私は-asyncオプションを付けて運用しているのですが、やっぱりiPad側のレスポンスが悪いですね。
再生停止ボタンを押してから2秒経った後にようやく止まるのが気にならないと言えば嘘になります。
とはいえ私の用途では致命的ではありません。
shairport-sync
shairport-syncというOSSもあります。もしかするとUxPlayよりこちらの方が有名かもしれません。
私は使っていませんが、UxPlayと比べた相違点としては下記かと思いました。
- AirPlay 2対応
- 32bit/352kHzまで対応（AirPlay 2使用時）
- 画面共有はできない
AirPlay 2に対応して嬉しい点としては、UxPlayでasyncオプションを付けて2秒遅延していたのが0.5秒遅延まで縮められます（！）。
ただしAirPlay 2ではなぜかALACではなくAACになってしまう場合があるようです。
良し悪しですが、shairport-syncはAirPlay 2を使うか否かをオプションで選べるので問題ありません。
全体的にUxPlayは画面共有が可能で、shairport-syncはオーディオ特化という印象を受けました。
私の用途だとshairport-syncの方が適切かもしれません。
試してダメだったこと
実はここに至るまでに色々調べていて、行き着いた先がUxPlayでした。
一応それぞれ可能ではあるので紹介します。
Zoomなどで画面共有
MacとiPadで同じルームに入って互いにマイクをオフにした状態で画面共有すれば音声も共有できるよね、の発想で試しました。
結論としては可能でしたが、この手のアプリにはことごとく時間制限があるので実用的ではありません。
大昔のSkypeのアカウントを掘り返してみましたが、これも数十分くらい経って追い出されてしまいました。
Zoom/Teams/Slack辺りなら有料プランを契約している方もいると思うので、契約済みなら良さそうです。
ちなみにiPad版Discordは画面共有に対応していません。
Google Meetで音声の共有が可能なのはブラウザ内だけです。
そう上手くはいかないか……。
サードパーティの有料アプリ
AirPlayレシーバーを追加するソフトウェアです。
調べてみたらこの分野は群雄割拠のようで、AirDroid CastとかTuneBladeとか色々ありましたね。
ほとんどが有料かつサブスクなのでちょっと手を出しづらい感触でした。
ただAirServerなんかは配信用途としても有名ですし、買い切りなのでかなり良さそうでした。
これが正攻法だと思います。
ちなみになぜ群雄割拠になっているかというと、動画や音声のローカルストリーミング配信技術が戦争状態だからです。
AppleはAirPlay、GoogleはGoogle Cast（Chromecast）を推し進めています。
iOSでは対応していないもののWi-Fiの標準規格にはさらにMiracastがあり、こちらも使われていますね。
できることはどれも同じなのですが、各社の理念や思惑がそうさせないのです。
というわけで別々の技術にすべて対応するためのソフトウェアがあったりします。
この状況は今だけの話で、そのうちどれかに統一されることでしょう。
個人的にはMiracastに統一してほしいですが、難しいような気もする
AirPlayを無理やり有効化
Mac mini 2018のAirPlayですが、実は機能としては内部的に存在するので有効化可能です。知ってた
調べるとリカバリモードでSIPを無効にした後に特定のコードを実行するとAirPlayを有効化できる方法（Reddit）が出てきましたが、macOS Ventura 13.0以降で使えなくなってしまったようです。
脆弱性ということで防がれたのでしょう。
macOS Montereyを使っている方はこの方法でもいいかもしれません。
しかし、この方法はSIPを無効化して運用する必要があるので危険です。
SIPにも色々あるので、やるなら必要なものだけを無効化しましょう。
私は試せませんでしたが、スクリプトの内容的にfsのSIPだけ無効化すればOKだと思います。
（自信はないです。間違っているかもしれないので試す際は自己責任でどうぞ）
csrutil enable --without fs※Macをリカバリーモードにして実行する必要があります
ちなみにMac miniを使っていてリカバリーモードに入るのが面倒な方は下記で強制的に入れます。
※Macのリカバリーモードは起動時に特定のキーを押しっぱなしにする必要があるのですが、Windowsキーボードではなぜか入れません。純正のMacのキーボードじゃないと入れない説すらあります
sudo nvram internet-recovery-mode=RecoveryModeDisk
sudo rebootちなみに上記とは別に、OpenCore Legacy Patcherを利用する手段もあります。
これを入れるとAirPlayを有効化できますが、これはmacOSのブートローダを乗っ取って改変する類のものでかなり大変な代物になっています。
主にサポート外のmacOSを無理やり入れることに使われますが、失敗するとMacが起動不可になります。
感覚的にはiPhoneで言うところのJailbreakに近いですね。
興味がある方はやってみてもいいでしょう。おすすめはしません。
Bluetooth
既に述べましたが、Monterey以降ではiOSとペアリングできなくなっているためNGでした。
私はMacにParallels Desktopを入れてWindowsを使っているので、Bluetoothレシーバーを挿してUSBの接続先をWindowsにすればWindowsとはペアリングできそうな気はしました。
ただトリッキーなやり方なので上手くいかなそうな気もしますし、レシーバーを買ってまでやるか……？ と思ってやめました。
（余談）Bluetoothは音質が劣化するのにAirPlayは劣化しない理由はなぜ？
Bluetoothが非可逆圧縮で、AirPlayが可逆圧縮（Appleはロスレス圧縮と呼んでいます）だからです。
可逆圧縮では劣化しません。
※AACで圧縮されて劣化する場合を除く
Bluetoothの圧縮方式には「aptX」「AAC」「LDAC」など色々ありますが、すべて非可逆圧縮なのでBluetoothという時点で劣化は避けられません。
感覚的に分かると思いますが、圧縮効率は可逆圧縮よりも非可逆圧縮の方が圧倒的にいいです。
なぜ非可逆圧縮にせざるを得ないかというと、Bluetoothの通信速度がWi-Fi等よりも遅いからです。
これはそういうものなので仕方ありませんし、そもそもBluetoothは今回の私のような用途ではアンマッチな技術です。
Bluetoothは無線イヤホンとか無線キーボードみたいなデバイスを想定した技術ですからね。
ただBluetoothもバージョンごとに安定性や通信速度が改善されていますし、音質劣化がほとんどない非可逆圧縮方式も最近は増えていたりします。
今後進化して可逆圧縮ができるようになったりして、音声用途ではBluetooth一択になる未来もあるかもしれません。
（最近のバージョンや圧縮方式に端末が対応しているかはまた別ですけどね。そもそもmacOSとiOSはペアリングできねえしな！！！！！！）
その点、AirPlayやMiracastはWi-Fi接続を前提にしているのである程度の通信速度が保証された上で成り立つ技術です。
AirPlayはALACという可逆圧縮ですし、MiracastはLPCM（非圧縮）に対応していたりします。
音質を保ちたいのであればこちらにしたいですね。
iPadにあるイヤホンジャック使えばいいんじゃね？
ええ、仰る通りです。
最近のiPadに3.5mmイヤホンジャックはありませんが、私が使っているiPadにはまだジャックがあります。
オーディオインターフェース（MOTU M2）にはライン入力できるので、これに接続すれば聴けます。
ただMOTU M2の仕様上、オーディオジャックの出力をそのままライン入力に入れるとモノラル入力になってしまいます。（＝TRSではなくTSのみの対応＝1つの端子ではステレオ入力ができない）
なのでステレオ音声を聴きたければiPadに挿した3.5mmステレオミニプラグ端子を2つのモノラル端子に変換する必要があります。
[iPadのジャック]-[3.5mmのステレオミニプラグ オス/オス]-[6.35mmモノラル標準プラグ×2 (白と赤)]で接続
これでiPadからのステレオ音声を聴けるようになるのですが、MOTU M2の入力は2つまでなんですね。
ステレオ音声を聴く時は入力が2つ占有されるので、マイクが使えません。
AirPlay環境の構築後は常時この配線にしています
とはいえ一応ちゃんと聴けはしたのです。
そう、本記事の環境を構築した一番の理由はこれをいちいち挿し替えたくないと思ったからです。
あとジャック経由で音声を送るとどうしてもアナログ入力になるのでオーディオインターフェースの高品質なDACを経由できないという今回の私の出発点を灰塵に帰す問題もあります。
せっかく買ったものを活かせないのは嫌ですね。
Type-C対応のiPadを買ってUSBによるデジタル入力が可能なオーディオインターフェースを買っても解決するのでしょうが、出費が嵩む……あとそれってiPadを充電しながら音楽を聴くことはできるのかな？
ちなみにMOTU M2の入力は2つともコンボジャックになっていて、XLRとTSプラグの両方に対応しています。
XLRで入力した時はマイク入力、TSで入力した時はライン入力に切り替わります。
2つ目の写真だと左がXLR、右がTSです。
UxPlayのおかげでマイクを常時接続しつつ、別途モノラル音声を入力したい時も入力手段を用意できるようになりました。
AirPlayなので音質劣化なし。さらにオーディオインターフェースのDACを通した音声を聴けます。やったぜ。
UxPlayの開発者たちには足を向けて寝られません。
UxPlayは主にUNIX/Linux向けのOSSなので、調べるとRaspberry PiをAirPlayレシーバーにする（！）記事が出てきたりします。
さらにこの記事で既に述べている通りなんとUxPlayはWindowsでも動きます。素晴らしい。神。
次のメイン機はMacではなくWindowsの予定なのですごく助かる。
ただCygwin想定っぽいので個人的にはWSL2で動かしたいところ
次はshairport-syncを使う手もアリですね。
楽しいぜ、Appleに抗うのはよ……。