Devialet Firmware 6.0.8とDevialet AIR 2.1への更新でわかったこと
iTunesが11.0.3へ（直後に11.0.4へ）バージョンアップされて生じたストリーミングソフトDevialet AIRのトラブルが解消されるべく，AIRが 2.0 へ，そしてすぐに2.1へ，また，D-Premierのファームウェアが6.0.7へ，そしてすぐに6.0.8へとめまぐるしいバージョンアップが続いた．
ファームウェアを6.0.8に更新した時点から，さすがに音切れや音飛びの現象はなくなり，かなり安定した動作を取り戻した．しかし，まだ万全とはいえず，（１）AIR自体が落ちる，（２）AIRは落ちないがD-Premier-WiFi 出力への接続が切れ，内蔵スピーカに移行してしまう，（３）接続が切れ，内蔵スピーカに移行することもしない，という現象が，ここ数日間で何回かずつ起きている．この「突然死」(SDS : sudden death syndrom)が起きると，アンプのファームウェアを再起動しない限りパソコンに再接続できなくなる．
他のユーザのシステムではどんな具合だったか，ネットのあちこちでいろいろ書かれているが，とくにフォーラム Has anyone heard the Devialet D-Premier Integrated Amp/DAC が参考になった（ネットでの議論の仕方も興味深い）．
我がシステムの場合，WiFiの強度は-31dBm程度で，不十分だとは思われない．むしろWiFi接続自体は以前より頑丈になり，台所で電子レンジを使用しても影響が出なくなったくらいだ．Time CapsuleとAirMac Express2（ブリッジとして使用）のファームウェアは最新のものに更新したが，その前後にこの現象が起きているので，関係はなさそうだ．
さて，トラブルはともかく，音質はどうか．また一段と生々しさを増した．ずっと聴いていると疲れるが，その疲れは不自然で不快な人工音から来るものではなく，演奏者の熱気や息使いの気配など，音の自然さと実在感があまりにも強く伝わり，おもわず力んで聴き入ってしまうからだ．あるいは，いつ起こるともしれないSDSへの恐怖に身構えて緊張しているからかも．
iTunesからの音データ処理を，OS X組み込みのCoreAudioに行わせる場合とAudirvana Proを使用した場合との比較も行ってみた．はっきりした違いは指摘できないが，強いていえばAudirvanaは色調が濃いのに対し，CoreAudioはより淡泊かな，といった感じだ．バグ症状の出方に違いはなかった．
新バージョンでもやはりフリーメモリ量が音質に影響を与える．以前と同様，音が何となく汚れてきたな，と感じたとき，フリーメモリ量を見ると10GB以下になっていたりする．そのとき，パソコンとD-Premierを再起動すると，音はあざやかに蘇る．聞きながらFree Memory Proアプリを使用してもその効果を知ることが出来る．
このトラブルを通じて改めて思うのは，バッファ管理の音質に与える影響である．パソコン（AIRアプリ）のデータ送信指令からアンプでの受信までにかかる所用時間が厳密に固定していれば，定まった時間通りに周期的に送信指令を出せばよいのだが，ストリーミングの複雑な過程の中で所用時間は変動するため，送受信の高度なタイミング管理が必要となる．この点こそが，普通のネット上のデータ送受信と異なり，オーディオのような厳格なリアルタイム性が要求されるデータ転送に伴う特有の難しさである．
以下のAIRストリーミングの説明は私の推測で，実際がどうなっているか確かではないが，当たらずとも遠からず，だろう．
ファームウェアによって動くアンプのマイクロプロセッサはバッファメモリから周期的にDACに1フレーム（左右チャネル各1wordの組）のデータを送り込む．CDフォーマットでは周期は44.1KHzで，1wordは16bitである．バッファ上のデータがこのように一定のクロックに従って刻々と費消されるが，バッファにある程度空きが出来ると，それを補充するべく，アンプはパソコンにデータ要求の情報を送る．パソコンのAIRはその要求情報に基き，メインメモリからデータを読み出し，複数のフレームからなるパケットを単位として，順次アンプに向けて送り出す．パケットがWiFiネットを経由してアンプに届くと，アンプはそれをバッファに追加する．DACによるバッファの費消にパケットの補給が間に合わなければ，バッファが空となってDACへのデータ供給に空白期間が生じ，音切れのもととなる．逆に補給が早すぎれば，バッファの空きの量を超えたパケットの後尾データが消えて音飛びのもととなる．
バッファでのこの種のデータの齟齬をそのままDACに伝えれば，過度な衝撃を引き起こし，アンプやスピーカを壊すなどの危険さえ起こりえるから，バッファからDACに行く直前に何らかの平準化（ショックアブソーバ）を行うモジュールを持つはずである．すくなくともボリューム調整などの機能を持つDSPが介在している．
下図は，AIRプレイ中のMacのアクティビティモニタでみたネットワーク状況である．これによってAIRとアンプのファームウェアがどのように連繋してバッファを管理しているかを推測してみる．
AIR以外のネットワークを使用するプログラムは動かしていないから，送信パケットの大半はアンプへの音データで，受信パケットの大半はアンプの，特にそのバッファの状態を知らせる情報であろう．毎秒24〜31パケットの受信をし，毎秒210〜230パケットの送信をしている．この例はCDフォーマットの場合で，ハイレゾでは当然ながらもっと多い．この図で見ると，本来一定であってほしいバッファへのデータ補給のタイミングには最大数msの揺れがある．グラフの赤線がしめす毎秒当たりの送信パケット数の変化をみると，まるでさざ波のように変動している．データ送信の所要時間が揺らぐため，その揺らぎを調節するべく送信するタイミングを早めたり遅らせたりしているからである．パソコンで送信指令を出すAIRは，バッファ状態などの情報を知らせる一種の送信要求情報をアンプから受け取るが，それが受信パケットである．グラフの青線が毎秒当たりの送信パケット数の変化を示す．AIRはこのアンプからの情報に基づき，予測を交えて音データの送信指令を出し，アンプのバッファに過不足がないように図っている．毎秒の送信データ量はCDフォーマットでは約175KBでいいのだが，WiFi経路に混入するノイズ対策としてECCなどにコード化するため，それよりも多い．
以前にも書いたが，従来のジッタ論議はあまり意味がなく，ディジタルオーディオの音質に大きな影響を与えるのはむしろこのバッファ管理ではないか，と今回のAIRのトラブルで改めて認識させられた．おおざっぱな目の子計算で考えてみよう．これまで論じられてきたいわゆるジッタは，せいぜい10ns以下で，その揺らぎによって各標本点の値（1フレームでの値）がオリジナルの正しい値からずれるエラーを問題にしている．それに対し，バッファのデータ補給タイミングの齟齬が起こすエラーは，各フレームの値がまるごと空になるか飛ばされるか，という現象で，オリジナルとは全く相関しない値が（平準化モジュールを介して）DACに与えられてしまう．AIR2.0が出る前，パソコンのフリーメモリが少なくなったときにハイレゾ音源をプレイすると音がグニャグニャするという現象が生じることをこのブログの以前の稿で書いたが，おそらくバッファ溢れが繰り返し続いたのだろう．また，ECCコードによる自動修正が効かないデータエラーが生じれば再送要求が発生し，それが繰り返されればパケットの到着がひどく遅れ，パケット丸ごと一つ以上の不足が生じれば，はっきりした音切れとなる．１パケットごと，つまり約5msごとに1フレーム以下の頻度の食い違いが起きるような場合，その頻度が高ければ，（平準化モジュールにより）音のアナログ的劣化として感じられるものになるだろう．いわゆるジッタがナノ秒単位以下であるのに対し，こちらはマイクロ秒単位であり，しかもオリジナルのデータとは全くの非相関な値となるため，音質を劣化させる程度はこちらのほうがずっと大きいのではないだろうか．そもそもナノ秒程度のジッタはバッファで容易に吸収されてしまうはずである．
いわゆるジッタ現象とバッファ管理のこの問題は，通常のCDプレーヤにも当てはまるように思われる．CDプレーヤの場合，CD上のデータ読み取りに伴うエラーの修正やワウフラの時間的揺れを取り去るモジュールが必要で，それが機能するために，CDからのデータを2KB程度のメモリに蓄えて，それに対してこの処理を行っている（Ken C. Pohlmann著 "Principles of Degital Audio", p.269の解説による）．このメモリがバッファの役割を果たすことになるから，ここに同様のバッファ管理問題が生じ，それはいわゆるインタフェースジッタやサンプリングジッタよりもずっと大きな影響を持つはずである．AIRの場合と同様，そもそもバッファ管理が正常に機能すれば，これらのジッタ（といわれるもの）はバッファによって吸収されるはずである．USB DACなども同様であろう．
アプリAIR2.1とD-Premier AIRのファームウェア6.0.8への更新で，バグ症状が治癒されただけでなく，正常な状態での音質がよくなった（と感じられる）のは，ソフトウェアの改良によってバッファ管理の確度がより高められたからであろう．
バッファへのデータ到達時間の揺らぎが度を超すことから齟齬がおこるが，その揺らぎのもとは，パソコンでのメモリ管理に始まり，他のプロセスやスレッドのCPUでの競合や，WiFi経路での競合など多くの変動要因によるものである．この変動幅を出来るだけ小さくすることが重要で，そのためには，可能な限り高速かつ大容量のメモリとストレージ，高速のCPU，さらに高速の（帯域幅の大きい）WiFiを使用し，情報の安定供給にできるだけの余裕を持たせることである．一般道と高速道とでは車の通過時間の変動幅が大きく異なるのと同じである．最近，WiFiに802.11acが現れ，ついにギガWiFi時代にはいった．残念ながらD-Premier AIRは対応していないので，現在の我がシステムに導入してもその効果のほどはわからないが，多少なりともWiFi経路の安定化に寄与するかもしれず，楽しみだ．
DA変換以前の純粋にソフトウェアによるディジタル処理からなる情報供給の部分がオーディオの最終音質に与える影響の大きさを改めて確認した．ということは，いまだ生じるSDSへの対策を含めたソフトの更新によって，さらに音質の向上がもたらされるかもしれない．Devialet社の，特にソフトウェアの技術陣に期待したい．
ファームウェアを6.0.8に更新した時点から，さすがに音切れや音飛びの現象はなくなり，かなり安定した動作を取り戻した．しかし，まだ万全とはいえず，（１）AIR自体が落ちる，（２）AIRは落ちないがD-Premier-WiFi 出力への接続が切れ，内蔵スピーカに移行してしまう，（３）接続が切れ，内蔵スピーカに移行することもしない，という現象が，ここ数日間で何回かずつ起きている．この「突然死」(SDS : sudden death syndrom)が起きると，アンプのファームウェアを再起動しない限りパソコンに再接続できなくなる．
他のユーザのシステムではどんな具合だったか，ネットのあちこちでいろいろ書かれているが，とくにフォーラム Has anyone heard the Devialet D-Premier Integrated Amp/DAC が参考になった（ネットでの議論の仕方も興味深い）．
我がシステムの場合，WiFiの強度は-31dBm程度で，不十分だとは思われない．むしろWiFi接続自体は以前より頑丈になり，台所で電子レンジを使用しても影響が出なくなったくらいだ．Time CapsuleとAirMac Express2（ブリッジとして使用）のファームウェアは最新のものに更新したが，その前後にこの現象が起きているので，関係はなさそうだ．
さて，トラブルはともかく，音質はどうか．また一段と生々しさを増した．ずっと聴いていると疲れるが，その疲れは不自然で不快な人工音から来るものではなく，演奏者の熱気や息使いの気配など，音の自然さと実在感があまりにも強く伝わり，おもわず力んで聴き入ってしまうからだ．あるいは，いつ起こるともしれないSDSへの恐怖に身構えて緊張しているからかも．
iTunesからの音データ処理を，OS X組み込みのCoreAudioに行わせる場合とAudirvana Proを使用した場合との比較も行ってみた．はっきりした違いは指摘できないが，強いていえばAudirvanaは色調が濃いのに対し，CoreAudioはより淡泊かな，といった感じだ．バグ症状の出方に違いはなかった．
新バージョンでもやはりフリーメモリ量が音質に影響を与える．以前と同様，音が何となく汚れてきたな，と感じたとき，フリーメモリ量を見ると10GB以下になっていたりする．そのとき，パソコンとD-Premierを再起動すると，音はあざやかに蘇る．聞きながらFree Memory Proアプリを使用してもその効果を知ることが出来る．
このトラブルを通じて改めて思うのは，バッファ管理の音質に与える影響である．パソコン（AIRアプリ）のデータ送信指令からアンプでの受信までにかかる所用時間が厳密に固定していれば，定まった時間通りに周期的に送信指令を出せばよいのだが，ストリーミングの複雑な過程の中で所用時間は変動するため，送受信の高度なタイミング管理が必要となる．この点こそが，普通のネット上のデータ送受信と異なり，オーディオのような厳格なリアルタイム性が要求されるデータ転送に伴う特有の難しさである．
以下のAIRストリーミングの説明は私の推測で，実際がどうなっているか確かではないが，当たらずとも遠からず，だろう．
ファームウェアによって動くアンプのマイクロプロセッサはバッファメモリから周期的にDACに1フレーム（左右チャネル各1wordの組）のデータを送り込む．CDフォーマットでは周期は44.1KHzで，1wordは16bitである．バッファ上のデータがこのように一定のクロックに従って刻々と費消されるが，バッファにある程度空きが出来ると，それを補充するべく，アンプはパソコンにデータ要求の情報を送る．パソコンのAIRはその要求情報に基き，メインメモリからデータを読み出し，複数のフレームからなるパケットを単位として，順次アンプに向けて送り出す．パケットがWiFiネットを経由してアンプに届くと，アンプはそれをバッファに追加する．DACによるバッファの費消にパケットの補給が間に合わなければ，バッファが空となってDACへのデータ供給に空白期間が生じ，音切れのもととなる．逆に補給が早すぎれば，バッファの空きの量を超えたパケットの後尾データが消えて音飛びのもととなる．
バッファでのこの種のデータの齟齬をそのままDACに伝えれば，過度な衝撃を引き起こし，アンプやスピーカを壊すなどの危険さえ起こりえるから，バッファからDACに行く直前に何らかの平準化（ショックアブソーバ）を行うモジュールを持つはずである．すくなくともボリューム調整などの機能を持つDSPが介在している．
下図は，AIRプレイ中のMacのアクティビティモニタでみたネットワーク状況である．これによってAIRとアンプのファームウェアがどのように連繋してバッファを管理しているかを推測してみる．
AIR以外のネットワークを使用するプログラムは動かしていないから，送信パケットの大半はアンプへの音データで，受信パケットの大半はアンプの，特にそのバッファの状態を知らせる情報であろう．毎秒24〜31パケットの受信をし，毎秒210〜230パケットの送信をしている．この例はCDフォーマットの場合で，ハイレゾでは当然ながらもっと多い．この図で見ると，本来一定であってほしいバッファへのデータ補給のタイミングには最大数msの揺れがある．グラフの赤線がしめす毎秒当たりの送信パケット数の変化をみると，まるでさざ波のように変動している．データ送信の所要時間が揺らぐため，その揺らぎを調節するべく送信するタイミングを早めたり遅らせたりしているからである．パソコンで送信指令を出すAIRは，バッファ状態などの情報を知らせる一種の送信要求情報をアンプから受け取るが，それが受信パケットである．グラフの青線が毎秒当たりの送信パケット数の変化を示す．AIRはこのアンプからの情報に基づき，予測を交えて音データの送信指令を出し，アンプのバッファに過不足がないように図っている．毎秒の送信データ量はCDフォーマットでは約175KBでいいのだが，WiFi経路に混入するノイズ対策としてECCなどにコード化するため，それよりも多い．
以前にも書いたが，従来のジッタ論議はあまり意味がなく，ディジタルオーディオの音質に大きな影響を与えるのはむしろこのバッファ管理ではないか，と今回のAIRのトラブルで改めて認識させられた．おおざっぱな目の子計算で考えてみよう．これまで論じられてきたいわゆるジッタは，せいぜい10ns以下で，その揺らぎによって各標本点の値（1フレームでの値）がオリジナルの正しい値からずれるエラーを問題にしている．それに対し，バッファのデータ補給タイミングの齟齬が起こすエラーは，各フレームの値がまるごと空になるか飛ばされるか，という現象で，オリジナルとは全く相関しない値が（平準化モジュールを介して）DACに与えられてしまう．AIR2.0が出る前，パソコンのフリーメモリが少なくなったときにハイレゾ音源をプレイすると音がグニャグニャするという現象が生じることをこのブログの以前の稿で書いたが，おそらくバッファ溢れが繰り返し続いたのだろう．また，ECCコードによる自動修正が効かないデータエラーが生じれば再送要求が発生し，それが繰り返されればパケットの到着がひどく遅れ，パケット丸ごと一つ以上の不足が生じれば，はっきりした音切れとなる．１パケットごと，つまり約5msごとに1フレーム以下の頻度の食い違いが起きるような場合，その頻度が高ければ，（平準化モジュールにより）音のアナログ的劣化として感じられるものになるだろう．いわゆるジッタがナノ秒単位以下であるのに対し，こちらはマイクロ秒単位であり，しかもオリジナルのデータとは全くの非相関な値となるため，音質を劣化させる程度はこちらのほうがずっと大きいのではないだろうか．そもそもナノ秒程度のジッタはバッファで容易に吸収されてしまうはずである．
いわゆるジッタ現象とバッファ管理のこの問題は，通常のCDプレーヤにも当てはまるように思われる．CDプレーヤの場合，CD上のデータ読み取りに伴うエラーの修正やワウフラの時間的揺れを取り去るモジュールが必要で，それが機能するために，CDからのデータを2KB程度のメモリに蓄えて，それに対してこの処理を行っている（Ken C. Pohlmann著 "Principles of Degital Audio", p.269の解説による）．このメモリがバッファの役割を果たすことになるから，ここに同様のバッファ管理問題が生じ，それはいわゆるインタフェースジッタやサンプリングジッタよりもずっと大きな影響を持つはずである．AIRの場合と同様，そもそもバッファ管理が正常に機能すれば，これらのジッタ（といわれるもの）はバッファによって吸収されるはずである．USB DACなども同様であろう．
アプリAIR2.1とD-Premier AIRのファームウェア6.0.8への更新で，バグ症状が治癒されただけでなく，正常な状態での音質がよくなった（と感じられる）のは，ソフトウェアの改良によってバッファ管理の確度がより高められたからであろう．
バッファへのデータ到達時間の揺らぎが度を超すことから齟齬がおこるが，その揺らぎのもとは，パソコンでのメモリ管理に始まり，他のプロセスやスレッドのCPUでの競合や，WiFi経路での競合など多くの変動要因によるものである．この変動幅を出来るだけ小さくすることが重要で，そのためには，可能な限り高速かつ大容量のメモリとストレージ，高速のCPU，さらに高速の（帯域幅の大きい）WiFiを使用し，情報の安定供給にできるだけの余裕を持たせることである．一般道と高速道とでは車の通過時間の変動幅が大きく異なるのと同じである．最近，WiFiに802.11acが現れ，ついにギガWiFi時代にはいった．残念ながらD-Premier AIRは対応していないので，現在の我がシステムに導入してもその効果のほどはわからないが，多少なりともWiFi経路の安定化に寄与するかもしれず，楽しみだ．
DA変換以前の純粋にソフトウェアによるディジタル処理からなる情報供給の部分がオーディオの最終音質に与える影響の大きさを改めて確認した．ということは，いまだ生じるSDSへの対策を含めたソフトの更新によって，さらに音質の向上がもたらされるかもしれない．Devialet社の，特にソフトウェアの技術陣に期待したい．
コメント
コメントを投稿