引用 作者: Musk 查看文章
printer這例子的確不錯, 但不太適合在此相較

假設以一個24/192的WAV音樂檔案約估700MB大小來說, 並以目前傳輸最快的NAS來搭配(65MB/S), 若要執行<End of Track>指令的話等於要播一首歌得先等個10多秒的空白, 我想應該沒人願意吧? 我猜廠方並非不知道這方式 但仍需以實用與人性化為最大考量為前提, FIFO應該是較佳的做法也就是循序存放及讀取
先謝 Musk 大前輩的稱讚. 不知道前輩覺得若真有這樣設計的產品, 能不能達到我所幻想的 Hi-End 效果, 而且真的有可能不受前端設備莫須有的干擾.

前面有回答過, 這種想法真正的目的是為了杜絕眾發燒友悠悠之口的. 其實我是沒那麼燒的IT人, 當然也覺得 FIFO 就足夠了.

24/192 700MB 這例子道出這solution的弱點, , 高人一出手, 便知有沒有.
不久未來的傳輸速度, 也許這就不是問題了.
有些話我是繞著彎講的. 現在呢? 大部份人燒了 16/44.1 多少年, 16/44.1 的 WAV檔才多大, 很多 1 秒不到就傳完了. Buffer 若足夠 Queue 個兩首歌在其中, 不就只有play第一首時要等個 1 秒.
我合理地猜廠方一定知道這方式, 但他們就是故意不做. 您說這有沒有可能? :o

好了, 不說了, 就此打住, 不說了. (sweat)(sweat)(sweat)