ni_ki様
修正をより正確に表現すると補間、類推になります。例えば前と後ろのデータから真ん中のデータを線形を仮定して推測する。勝手に都合良く化粧することです。しかし0.5秒の音切れを自然な形で補間することは出来ないでしょう。
LAN上では、圧縮データが遣り取りされている。AME はバッファーに受け取ったデータを一時保管しそれからPCMデータを作り、内部DACはそれをアナログ化し、別に光SPDIF信号を作っている。問題が起こるとすれば圧縮データ=>PCMデータのプロセスでしょう。ここでいろいろな音質制御が行われている様です。このようにすれば音声の制御性は増加するが処理に時間が掛かります。AirPlayの形式を知らないからそれ以上コメントできません。
再送に関しては、再送されたデータは通常バッファーのお尻に置くからデータの時間関係が狂い音声では通用しないでしょう。
やすどん様
AME の情報伝送システムに問題があれば、AMEとしては致命的です。私の経験では、iTunesでAME外部スピーカに無線で音声を送っているときの伝送レートはせいぜい80~90 kB/sです。AME の能力の1/10~1/50しか使用していない(推測)。その状態でAMEのバッファーが空になるとしたらいかなる原因を考えたらよいのでしょうか。空の情報がMACに届いていないか、AMEが失神していてその情報をMACに発信していないか、MACが送ったデータをAMEが受け取っていない(途中で消えた?)か、のどちらかです。何故に??バッファーが空ならバケット数は逆に増えるはずです(ni_ki氏の実験)。バッファーが満杯だと考えた方が自然です。又はオーバーフローしている?
それを調べる方法として、PCM信号のクロック周波数を変えたり、ビット長を変える、音声の帯域幅を変える、要するにAMEに対する負荷をソフト的に変えることが考えられる。バッファー容量が足りないと考えるならば、バッファーの不足を回避する方法です。
AMEの処理速度が遅いから、SPDIFのジッターが大きくなると考えています。処理速度がジッターを決めてしまう。信号処理がマスタークロックに追いつかない状況が時々発生するという事です。PLLを出力段に入れると、大きなジッターが発生したとき音が途切れてしまうので都合が悪いでしょう。だから入れられない。