走向超值而極緻的 HI-FI電腦訊源（連載）

[LSP000]

USB input的power應該是直接被捨棄, 因為5V除非經過升壓, 不然沒辦法經過濾波和重新穩壓後, 仍然有5V的電壓.
而這塊板子上, 不見升壓電路, 所以小弟才判斷USB input power是捨棄不用的.
而小弟也記得, iUSBpower如果不接9V外接電源, 是無法工作的.

power地線上的處理, 應該就是小弟上文說的, 左上角那塊電路.

嗯, 我也有印象, 香港的論壇上提過 iUSBpower 如果不接9V外接電源, 是無法工作的.

USB input 的 power 和 外接 9V power 的地線是不是應該會接通?
power地線上的雜訊, 如果也經過有效地處理, 是不是就更完美了?

[bchsieh]

整塊電路板, 看圖說故事, 依小弟的猜測應該大概是這樣的:

* USB data部分: 直接經由電路板上方的"Impedance Matched High Speed USB Data Path"送到USB輸出端.

* isoearth部分: 由電路板左方的"Ground Management"來做控制.

* 參考電壓部分: "Constant Current Generator"提供恆流源給"Precision Voltage Reference"產生穩定的參考電壓, 再經過"Three Stage UXLF Reference Noise Filter"的三階段濾波把參考電壓的雜訊濾除後, 送給"Ultra Low Noise Super Regulator"的穩壓IC"U1"當做參考電壓.

* USB電源部分: 由左上角"DC 9V"輸入後, 送到左下角經"F1"磁珠先做初步濾波和"D10"二極體做DC極性保護後, 送入"Three Stage Sixth Order RF Noise Filter"用LC濾波除去9V DC交換式電源的高頻雜訊, 再送入"Ultra Low Noise Super Regulator"穩壓後產生5V, 最後分別送入上下兩個USB輸出端子.

* 接地處理部分: 分別在四個角落, 用四組電容和電阻並聯的方式, 做接地隔離 (C1&R1, C2&R2, C31&R10, 還有C30&R7).

[bchsieh]

嗯, 我也有印象, 香港的論壇上提過 iUSBpower 如果不接9V外接電源, 是無法工作的.

USB input 的 power 和 外接 9V power 的地線是不是應該會接通?
power地線上的雜訊, 如果也經過有效地處理, 是不是就更完美了?

USB input 的 power 和 外接 9V power 的地線有沒有接通, 小弟猜測是用ground management的開關來控制.
power地線上的雜訊, 在Three Stage Sixth Order RF Noise Filter裡, 有用電感做處理 (L4 和 L5).

[LSP000]

整塊電路板, 看圖說故事, 依小弟的猜測應該大概是這樣的:

* USB data部分: 直接經由電路板上方的"Impedance Matched High Speed USB Data Path"送到USB輸出端.

* isoearth部分: 由電路板左方的"Ground Management"來做控制.

* 參考電壓部分: "Constant Current Generator"提供恆流源給"Precision Voltage Reference"產生穩定的參考電壓, 再經過"Three Stage UXLF Reference Noise Filter"的三階段濾波把參考電壓的雜訊濾除後, 送給"Ultra Low Noise Super Regulator"的穩壓IC"U1"當做參考電壓.
9V

* USB電源部分: 由左上角"DC 9V"輸入後, 送到左下角經"F1"磁珠先做初步濾波和"D10"二極體做DC極性保護後, 送入"Three Stage Sixth Order RF Noise Filter"用LC濾波除去9V DC交換式電源的高頻雜訊, 再送入"Ultra Low Noise Super Regulator"穩壓後產生5V, 最後分別送入上下兩個USB輸出端子.

* 接地處理部分: 分別在四個角落, 用四組電容和電阻並聯的方式, 做接地隔離 (C1&R1, C2&R2, C31&R10, 還有C30&R7).

謝謝 bchsieh兄詳細地分析!
這玩意兒對我這種暫態反應要求不高的人而言, 已經夠滿意了.... ^___^

[psycho]

有一位同好問到：

你好

小弟現在是
NEC3.0 PCI-E擴充卡--yu studio低價USB3.0分離線(5V 3.6A變壓器)--3.0HUB--yu studio低價USB 2.0分離線(5V 3.6A變壓器)--DAC

想問一下 您在走向超值而極緻的-HI-FI電腦訊源 page116 提到使用3.0轉接頭
但是有人告訴我3.0的線揷不進2.0設備 所以我HUB到DAC才會買2.0分離線

所以如果我買條USB 2.0發燒線接您所謂的3.0轉接頭 從HUB--DAC這段 在HUB 3.0這頭是沒什麼問題 但在DAC這頭是2.0的設備 請問如何揷上~謝謝?

這麼相信我的推薦，應該加分！....

我們使用的 USB DDC或DAC是樂之邦的產品，原是使用 USB 3.0 的接孔，所以我們才需要使用 3.0分離線。如果你的DAC本身是 2.0接孔，那當然、絕對不可以使用 3.0 的線啦！而且理論上也沒有必要才....

但是使用 3.0 HUB的話，從電腦到HUB就一定要使用 3.0的線，這個非常正確。

此外，不知道你使用那一台DAC？除非非常便宜不到5仟元，否則我都是強烈建議一定要把 USB DDC與 DAC分開，這個奇效會比 2.0線升級成 3.0線還要重要很多喔！.....

[psycho]

簡論 JPLAY 5.0 版的能耐與 雙電腦播放 的效果

我會建議『不必急著試』，因為 5.0 版『有可能比不上 4.X版』，而雙電腦播放的效果有很多條件是很難達成的。

首先談聲音。在我的 CAT 1 號直接以 5.0 PK 4.3，基本上5.0的聲音比較討好HI-END族，但是不見得更正確。可能要去 rendzaw店裡用大號角測試才能見真章。

我的兩台電腦分別是軟體優化到相當極緻的 cat 1 號與只優化一點點的 U80V筆電，開啟工作管理員監視電腦情況後，基本上發現雙電腦播放的電腦流程是：

control PC 讀音樂檔，讀進自己的保留記憶體 => 網路 => AUDIO PC(沒有進入保留記憶體！！)=> AUDIO PC的 USB DDC => DAC。

假設 CAT 1 直接 03 USD 的聲音是90分，而 U80V 直接 03 USD的聲音是 50分的情況下

CAT 1 遙控 U80V，從50分瘋狂進步到70分！
U80V 遙控 CAT 1，對不起，從 90 分 退步到 75分。

很明確的，如果你的 CAT 或 PC 的優化是不合格的情況下，雙電腦播放的確有極強的改善效果。但是如果你的CAT己娙優化極緻了，那麼加上一台優化不合格的 U80V，基本上是『倒扣』這麼嚴重！

其實先前拜 rendzaw的研究所賜，5.0版的jplay 雙電腦播放，可以想像成 CAT => NAS => AIRPLAY；連AIRPLAY這種情況下，CONTROL PC是否優化都會出現天差地遠的現象，當然在 JPLAY 5.0版也發生相同的現象了。

因此我的猜測是：雙電腦播放『的確有效』，但是CAT本質不能差太多！也就是說，當我己有一台化極緻的CAT了，如果再搞一台相同水準的 CAT，那麼雙電腦播放應該可以加分；但是如果隨便拿一台不合格的CAT來雙電腦播放，那百分之兩百是扣分！

於是大家可以非常客觀地測試你自己的CAT優化究竟合不合格了.... 試試雙電腦播放吧！如果比直接播放強，你的CAT就可以砸了.....

我個人是覺得，JPLAY的軟體改善效果己經快到頂了，後續的改善有限，所以再要玩就得直接搞定CAT本身的體質了。

當然 5.0版 JPLAY 之雙電腦播放有很多非常非常方便操作的優點如下：

1、H模式可以快速停止，電腦也比較不會常當機了，其實還是會當......

2、H模式是把 AUDIO PC H掉，CONTROL PC是可以做其他事的。所以在 H 模式之下，使用FOOBAR、ITUNES.....與 JPLATY MINI的差距大幅縮小！不過還是有差......

3、AUDIO PC的優勢在於，可以把螢幕、鍵盤...通通拔掉（像不像一台NAS...），就可以得到最佳音質了！！可惜的是，即使做到這種地步，我的CAT 1被 U80V搖控之下，還是被U80V拖累了。

4、真正發燒的瘋子，組兩台極端優化的CAT吧！.... 等我去 rendzaw店試試看用我的 cat 1 去遙控他的 cat，猜想這會是最佳組合。

[psycho]

有沒有英文夠強的網友幫我翻譯指正一下？.........

我看到 JPLAY 原廠網站討論有這麼一段：
http://jplay.eu/forum/jplay/jplay-5-released/page-3/

Dears,
There are three questions about jplay5.
According to Joseph's reply , Jplay5 with foobar will automatically preload current music to memory.
I remember the previous version of Jplay will occupy a "consequence memory" for better sound quality, but in Jplay 5 the cache memory size is only available in jplay mini.
Does it mean
1.The preload step in Jplay5 will not load the music into a consequence RAM ?
2.The sound quality of Jplay mini is better than foobar+Jplay ?
The last question is
engine/buffer/Bitstream in settings have no effect in ASIO,but we have to choose ASIO: Jplay driver in foobar.
Does it mean these three settings have no effect when we use foobar?
Thanks

發文者 sniper0710應該是本站網友，他的英文我完全看得懂！但是原作者的回答我就看不懂了....

sniper0710 – i never said what you say i dis but ok, i can see your confusion so let me try to explain:

- _nothing_ has changed in terms of how JPLAY allocates and uses memory for v4 apart the option for user to choose size of RAM used as we found that smaller values sounded better and as there is no need to allocate GBs of RAM when streaming approach is used

- mini has its own cache as we wanted to be really anal about having the whole track in RAM before playback starts: call us nuts but that is what we wanted – note mini's cache is _separate_ and has nothing to do with JPLAY's service internal buffer which has a fixed size (as explained above)

what this means is that only mini will preload complete track in RAM – Foobar/Jriver can do that too but it's up to you to select their respective options for it and from what we hear from people it actually sounds better when those options are off…

and, finally, to totally confuse you, in all cases, JPLAY Driver will stream portions of track being played to JPLAY Audio Service which, as mentioned, will use contiguous RAM for music storage/playback

- for question 2 you don't need us to tell you which one is 'better': you can listen and make your own decision…

- Engine/Buffer/Xtream have no effect ONLY if you select ASIO output in JPLAY Settings panel (as ASIO interface does not support those) – it has _nothing_ to do with Foobar…(you just select JPLAY Driver there)

首先直接猜測原作者的意思可能是：

1、JPLAY 4.X版『指定記憶體』的方式與5.0版完全相同，這種記憶體都是越小塊越好聽。

2、JPLAYMINI程式所需要 CACHE 的 MEMORY 是 JPLAYMINI 專用的，只是用來進行預載功能，與第 1 個的『指定記憶體』無關。反而與 FOOBAR2000之類的預載入MEMORY功能類似，只是後者常常反而不好聽。

3、無論使用什麼界面，只要經由JPLAY AUDIO SRIVICE發聲，就都是連續記憶體。

其他兩個問題的答案不重要或原作者『應有保留』所以我不管了。

就回答『連續記憶體』一事看來，前面三個答案極可能相互矛盾；應該是涉及內部機密所以不敢講太多....

想先請大家看看我上述的翻譯正不正確？再來吐槽原作者是否是保留答案....

基本上請大家相信自己的耳朵，自行測試是否與我相同：

1、即使使用ASIO界面，指定 BEACH、RIVER、XTREAM百分之百有差別。
2、JPLAYMINI 絕對狂電 其他播放程式 + JPLAY界面；
3、我比較相信是 5.0 版找到一種幾乎聽不出差異的『連續記憶體』方法，例如以下猜測：

每 X ms就關閉所有硬體中斷，以 256K 為BUFFER，先填滿這塊記憶體，然後往音效卡送出 256k 的資料，再開放所有硬體中斷 X ms，然後重覆所有動作。

這樣子的好處是理論上只會造成 X MS的錯覺頻率，相對降低了隨機JITTER造成的音質干擾。

而且這只是針對方波間的JITTER而己，說不定 JPLAY發現了方波內JITTER更重要；所以稍稍放棄一點方波間的完美，加強方波內的正確生，最後聽起來仍然是5.0 > 4.X，就可以自圓其說了。

總而言之，真的完全不相信原作者上述的說詞，除非是我英文太破看不懂....

[bchsieh]

小弟沒用過jplay, 不過從作者的意思來看, 小弟的猜測如下:

1. 除了jplay mini以外, 其他的播放程式+jplay皆不會把整首曲子全部預載到記憶體上.
2. jplay只有在小塊buffer使用連續記憶體, 而預載記憶體並非連續記憶體. 這部份應該跟P900/高醫師前輩的系統不同.

小弟在linux上使用的是mpd (http://en.wikipedia.org/wiki/Music_Player_Daemon), 是一個輕巧又好用的音樂伺服器, 可以使用電腦/手機/ipad/iphone遙控播放.
雖然聲音已經很好, 但是好還要更好, 所以小弟正在修改mpd程式, 也得以一窺播放器的內部運作.
以mpd來說, 使用者可以自行設定buffer大小, 但是在mpd內部, 其實是把這個buffer切開成為多份記憶體, 每份固定為4K大小. 播放的時候, 每次把最前面的那份4K記憶體內的資料丟給音效卡, 然後釋放這塊記憶體, 接下來再丟出下一份4K記憶體內的資料給音效卡. 所以在記憶體裡面就是一堆以4K為單位的區塊, 組成buffer.
也因為linux的pagesize就是4K, 所以每塊4K記憶體都是連續記憶體.
感覺上, jplay的運作方式好像也是類似如此.

以上對jplay的部份皆為小弟的猜測, 如果有誤, 恕小弟不負責...

[LSP000]

bchsieh兄軟硬通吃, 強!

P900兄強調要改寫音效卡driver才會有好聲, 我想應該就是要避開這個以 4K區塊為單位組成的 buffer, 所帶來的負面影響; 相反地, 他們好像是要求 real-time "產地直送". ;-)

[bchsieh]

bchsieh兄軟硬通吃, 強!

P900兄強調要改寫音效卡driver才會有好聲, 我想應該就是要避開這個以 4K區塊為單位組成的 buffer, 所帶來的負面影響; 相反地, 他們好像是要求 real-time "產地直送". ;-)

LSP000兄, 強者都是不出聲的, 小弟只是純粹愛玩而已..

小弟相信音效卡driver一定是個大瓶頸, 但player應該也是個不小的瓶頸. 每突破一個瓶頸, 應該都可以進一大步.
改寫音效卡driver, 有兩個很重要的前提. 一個是可以取得原始碼, 另一個是原始碼是否不用經過重度改寫就很容易優化.
以小弟使用的linux來說, 最大宗的driver就是alsa, 另外一個是oss. 小弟目前已經從alsa換成oss, 聲音好了不少. 而這兩者的原始碼都可以輕鬆取得, 所以改寫音效卡driver的第一個前提, 已經不是問題了.
大部分的問題都是出在第二點. 如果原始碼的程式邏輯, 距離優化所需要的邏輯相差太大, 則整個程式可能直接重寫還比修改還來得快. 這部份值不值得花時間去做, 就變成投資報酬率的問題了.
小弟猜測P900前輩會選擇改寫RME的驅動程式, 一方面是RME的硬體規格很不錯, 另一方面是其驅動程式偏向底層直接控制音效卡硬體, 而非windows本身的API, 所以不用經過重度改寫就可以達到目的. 這算是原始驅動程式的體質問題.
小弟研究過alsa的USB audio驅動後, 選擇換一條跑道, 改成OSS. 而後又因為OSS對USB audio的支援度不夠, 改成跑hdaudio. 而使用內建音效也是小弟後期的目標之一, 所以換成oss hdaudio, 小弟很樂觀其成.

等mpd在小弟能力範圍內, 改到不能再改之後, 小弟會把重心放到OSS hdaudio驅動上面. 不過那又不知是何年何月了..
其實最理想的方式, 還是player+driver直接寫成一個軟體, 才是真正的直通, 但工程實在太浩大.
而P900前輩的方式, 小弟相信是以最少的努力(但已經得花非常多功夫了)達到最接近上述條件的方法了 (小弟相信P900前輩的OS, 播放過程中一定還是有動到buffer, 只是比普通情況少了非常多層buffer, 而且大小也小了許多).