実験準備
AirMac ExpressのファームウェアはApple Base Station V6.3とある。これで、ネットワークの使用状況からデータの流れを推測する。ネットワーク状況の確認にはMac OS X付属のアクティビティモニタを使った。実験用に最低限のアプリケーション以外を終了。アイドル状態ではネットワークを流れるデータ量は送受信ともにほぼゼロになっている。
なお、AirMac Expressで使われているプロトコルは、RAOP（Remote Audio Output Protocol）という名前がついていて、詳細は非公開らしい。
実験1
iTunesからリモートスピーカを選択して、ローカルの音楽を再生してみると、それまでほぼゼロだった送信データ量が100KB/sくらいになる。これが送信されている音楽データと見て良いだろう。
実験2
次にリモートの音楽を、ローカルのコンピュータのスピーカから流してみる。すると、受信データ量が20KB/sくらいになる。送信データ量はほとんどなし。さきほどの送信データ量と今回の受信データ量が違うのがちょっと気になる。
実験3
ここで、リモートの音楽を、リモートのスピーカから流してみる。パッシブFTPのような動作になっていれば、送信、受信ともにデータ量はほぼゼロを保つはず。
でも、実際には、受信データ量が20KB/sで送信データ量が100KB/sと、最初の2つの実験をちょうど合わせたような状況となった。
結論
現行の iTunes、AirMac ExpressによるAirTunesでは、リモートの音楽をリモートスピーカで流すときでも、いったん受信してから送信している模様。
考察
実験1と実験2の比較でも、実験3でも、受信データ量より送信データ量が多い。これは、高い演算能力があるコンピュータ間の転送では音楽データを圧縮した状態で送受信し、演算能力の低いAirMac Expressへは伸張した（もしくはあまり演算能力がいらない）形で送信しているためではないかと思われる。
AirMac Expressに送信するためのデータ伸張やデコードに負荷がかかるとすると、それをリモートのコンピュータにやらせるより、「受益者負担」的にリクエストを出しているコンピュータで処理する、というのは納得できる。ただし、リモートのコンピュータを専用の共有音楽サーバとして利用するような場合、データ伸張なども含めてサーバに負荷を集中できるような使い方もできると良いと思う。
