こんばんわ。
ごく稀に音飛びが発生する可能性は、どうしても否定はしきれません。1時間に1回はちょっと多いような気がしますが、わたしの環境でも数か月に1回くらい、突然に発生することはあります。数秒間再生が止まって、その後何事もなく再生が継続します。そのときにはPlayer ViewのDECDインジケータが点灯して、デコーダ待ちが発生したことを示していました。
自分の環境ですから、その後仔細に状況を調べたところ、見た目のままデコードスレッドが一時的に動作していなかったことがわかりました。なぜ動作していなかったのかについては、確たるところはわからず、以下の2つの可能性しか思い至りませんでした。
- Windowsのスレッドのスケジューリングが停滞した.
- ログ出力のためのディスクI/Oが停滞した.
わたしの環境では、問題発生時に備えるため常時ログをディスクに出力しています。皆さんのところではログをディスクに出力するようにはしていませんので、とくにRAMDecodeをご利用の場合は、2番目の問題は発生しません。
1番目の問題は、WindowsというOSの原理上、発生してもおかしくはありません。詳しくは省略しますが、WindowsはいわゆるリアルタイムOSではないためです。ただ現実にはマルチコアCPUが一般的になり、その性質が表面化することは現実にはほぼありません。わたしのところでも、仮にこれが原因だったとしても、上に書いたように数カ月に1回とか、そういう確率です。
tocchik1962さんの環境では、すでにRAMDecodeご利用になっているようですので、ディスクI/Oの問題はなさそうに見えます。すこし気になるのは、「DSD5.6・11.2MHz、PCM384kHz/24bitあたり」というと、1曲のサイズも相当大きくなると思いますが、それに対してメモリ8GBはちょっと心許ないかも、という点です。
実装メモリ容量が少ない環境への対策として、自動モードのRAMDecodeの場合、TuneBrowserは対象の曲数を自動で調整してメモリの圧迫を抑制します。ご存知と思いますが、Windows (に限らずたいていのOS) は実装されているメモリ容量以上のメモリをアプリケーションに提供できるようにしています。アプリケーションにはメモリと見せかけて、実際にはディスク上にその内容を移しておく、いわゆるスワップとかページングと呼ばれる操作です。これが発生すると、結局はディスクI/Oが発生することになるので、TuneBrowserは上記のような抑制策をとっています。
ただ、いくらTuneBrowserが自粛したとしても、ほかのアプリケーションがメモリを使用していたら結局スワップは発生しますし、Windowsの判断によってはほかのアプリケーションのためにTuneBrowserの実メモリ割り当てを削減してしまう可能性もあります。そしてスワップは時として非常に重たい処理になることもあります。
音飛びの要因がこれだとは断定はできませんが、いただいた情報からぱっと気がついたのは、このような点でした。