
-
2016-07-22, 05:44 PM
#2931
 作者: Higuma
HQPLAYER不能完全關閉DSP,單純decode輸出嗎?
照理說應該會在UI中提供disable的選項??
國外已經有人試過了.. 用盡各種方式,輸出仍非bit-perfect。
-
-
2016-07-22, 09:11 PM
#2932
 作者: bchsieh
國外已經有人試過了.. 用盡各種方式,輸出仍非bit-perfect。
原作者的奇怪堅持嗎XDD
-
-
2016-07-22, 11:21 PM
#2933
 作者: bchsieh
國外已經有人試過了.. 用盡各種方式,輸出仍非bit-perfect。
bchsieh大,可以提供國外這部分的連結嗎?小弟想看一下試過的測試方式,想要思考一下這個問題,感謝您
-
-
2016-07-23, 12:14 AM
#2934
 作者: pcherng
bchsieh大,可以提供國外這部分的連結嗎?小弟想看一下試過的測試方式,想要思考一下這個問題,感謝您
pcherng兄,請看下面討論區:
http://www.computeraudiophile.com/f1...3/index76.html
一直討論了大約十頁。
這位仁兄的帳號叫做tranz,DAC是MSB,有特異功能,播放特別測試檔案,DAC就可以知道是否為bit-perfect播放。
HQPLAYER的作者Miska也有參與討論,不過看來作者本身也不知道為什麼測出來非bit-perfect。
tranz有用其他的播放器做測試,都可以進行bit-perfect播放,就只有HQPLAYER不行。
所以證明並非是作業系統或是音效驅動程式的影響。
對了, tranz用的是Mac,但沒有道理HQPLAYER在不同作業系統下會有不同的表現。
-
The Following 3 Users Say Thank You to bchsieh For This Useful Post:
-
2016-07-23, 12:43 AM
#2935
也來回報這一個月來抓長芯盛偶有爆音不連續或斷訊的問題。依照前面的觀察到的現象我在adaptor上下放了散熱片(p286)先來觀察看看如果把本體加強散熱是否有甚麼變化,前面的現象改變了甚麼? 這期間也嘗試聽聽別的撥放軟體換成了KORG Audiogate 4.02,也入手一台DS-DAC-100把軟體的限制打開聽聽DSD的檔案,此部分與先前的使用環境不同,暫時把數字時代2收起來打算另組一台時再請出來玩玩。先前使用數字時代2時當異常發生時的狀況變成是音樂撥放的當中會停掉失聲了,必須結束撥放軟體再重新執行與DAC連線。沒找到root cause,但是我注意到了撥放軟體會斷掉聲音是因為dac的斷線狀況,突然想起用在100V的CDP和唱盤的隔離變壓器二次側有三種電壓規格,改了一下接線並把AOC兩端吃5V的變壓器,長芯盛adaptor的電供,dac的電供全部接上這個隔離變壓器上的排插,呦呦呦 沒再發生過異常了! 小弟猜想我的問題極有可能是市電帶入的突波,壓降等等的問題引起的狀況,如果有這方面問題的朋友可以朝這方向試試有沒有幫助。
-
The Following User Says Thank You to pcherng For This Useful Post:
-
2016-07-23, 01:25 AM
#2936
 作者: bchsieh
pcherng兄,請看下面討論區:
http://www.computeraudiophile.com/f1...3/index76.html
一直討論了大約十頁。
這位仁兄的帳號叫做tranz,DAC是MSB,有特異功能,播放特別測試檔案,DAC就可以知道是否為bit-perfect播放。
HQPLAYER的作者Miska也有參與討論,不過看來作者本身也不知道為什麼測出來非bit-perfect。
tranz有用其他的播放器做測試,都可以進行bit-perfect播放,就只有HQPLAYER不行。
所以證明並非是作業系統或是音效驅動程式的影響。
對了, tranz用的是Mac,但沒有道理HQPLAYER在不同作業系統下會有不同的表現。
越來越詭異了,原作者自己都不知道為何無法單純輸出?
就data層級,沒有coder無法控制的變因吧?
其實要測試也很簡單,用錄音卡做自身DO/DI錄音,
再拿原檔案比對就行了.........可有網兄測過?
-
The Following User Says Thank You to Higuma For This Useful Post:
-
2016-07-23, 03:48 AM
#2937
感謝bchsieh大提供的連結文章,今天來看到教授也聽了兩個檔案後的感覺,呵呵~ 確實不是業障重,聽到都不是假的!!! XD 因為在myav上除了那個令人生氣的傢伙外就G660606大有發表聽感
myav john大提供的兩個檔案小弟初時聽到兩個結果,這兩個結果分別是用audiogate 4.02和 hqplayer聽到的,安裝audiogate 4.02的是參考機,沒有特別什麼原因去做設定,只有一點就是選擇低耗能的amd apu 2650的平台來聽音樂,當初只希望利用apu的特性與長時間聆聽時可以不要太耗電就好,也由於cpu不強,所以使用的撥放軟體也就試一些跑起來不耗資源的撥放器,一開始用myav的sigma大寫的playwave,因為用asio所以就某程度而言符合bit-perfect。
先說說這兩個檔案聽到不同的結果來說一下,起初是放到htpc上去聽,老實講我聽到兩個檔案撥放起來沒有差很大,幾乎是一樣,重複聽各十來次真的沒有聽到很明顯的差異,OK,後來G660606大說了cuda的聽起來比較有立體感,想了一下換工作用的NB內的hqplayer來聽看看好了,結果真的很容易聽到不太一樣的結果,cuda聽起來樂器間的位置形成的定位感不同比較好,空間殘響的所形成的音場及堂音也比較好,強弱的對比cuda的也比較好,我分別用winhex和spek再確認一下,確定是沒有不同處,雖然rip條件不同時產生的聽感在citymaster那玩過確實有差,是甚麼原因真的不懂!
比較慶幸的是教授用雙機流+jplay H模式可以消除rip差異的結果在小弟的htpc也相同 XD
因為這個問題今天下班前玩了一個小小的測試,用AMD Radeon RAMDisk做一個800mb的R:出來,把兩個檔案放在兩個資料夾順便把檔名一致,再分別把檔案複製到R:內用hqplayer聽,每次R:內只有一個檔案,如果要換cuda的就format R:後再複製進R:
挖糙~ 真的很認真的聽了幾次後 這是第三個結果,可是差異性縮小了,有趨近htpc上的聽感但還是有不一樣的地方
真的,小弟還是要說應該不是"業障重,聽到都是假的",看到bchsieh兄說到國外測試hqplayer是不是bit-perfect的測試方法時小弟好奇了,從p76-p86間review quickly兩次,除了在p79內的#1958的bogi兄用ramdisk取代usb disk來聽音樂有獲得比較好的聲音細節外就沒有其他人用ramdisk來測試了
ramdisk的測試是突然閃過的念頭,靈感來源是在P900大的討論串提到有切一個ramdisk出來,當要撥放音樂時會把檔案複製到ramdisk去再撥放,如果聽一聽覺得怪怪的在執行一個程式類似清黑膠上面的灰塵把ramdisk整理一下,另外就是貓窩工坊的陳大也提到過,比對都沒有差異的兩個數位音樂檔聽起來不同時除了jitter外還要考慮的是執行時資料的一致性是否相同,是不是在磁碟內一樣的位置,loading到ram時的位置是不是相同的地方,這都要考量進去的問題。
再來,使用sigma大的playwave時最讓小弟收穫很大的地方就在一連串的4.x.x的改版經驗,sigma大有提到發聲的工作是驅動程式與os的事,playwave改變聲音的地方就僅在每次嘗試把資料送到driver的方式做的變動,有興趣的可以參考http://www.myav.com.tw/bbs/showthrea...eadid=20459807
其中小弟領悟到資料傳送的方式會有兩個層面現象,改變與改善致正確的再現
小弟假設一個可能性hqplayer不是bit-perfect的問題會不會是資料傳遞給驅動程式其實已經有改變了而沒有正確的再現。
小弟做的ramdisk實驗提出來,看看有沒有其他有興趣測試的大大試試看看這個結果有無差異,呵呵呵~ 小弟倒是希望是我"業障重聽到的是假的"
hqplayer小弟有很大的興趣,聽過citymaster大的系統及看了幾位大大用的經驗後躍躍欲試,打算把另一個閒置的ga-990fxa-ud7+1045t依照john大的建議,弄一個加料很誇張的系統玩玩!
小弟看法是除非作者找到原因不然真的不要期望這個hqplayer是嚴謹的bit-perfect方案
此篇文章於 2016-07-23 04:02 AM 被 pcherng 編輯。
-
The Following 4 Users Say Thank You to pcherng For This Useful Post:
-
2016-07-23, 04:06 PM
#2938
我沒有時間細想這個問題,目前粗略的猜測是:
JPLAY派或者聲音偏向JPLAY派的CAT播放理論,基本原理是CAT的運算速度越快越好。但是追求效能的嚴重副作用就是『躁感』(可能來自高速運算的電磁訊躁)會上升,於是後端調整要不像我一樣就是用超大暫態來躲問題、不然就是想辦法濾掉躁感如JPLAY作者們推薦的音響器材。
而CUDA的出現,似乎『分擔了』部份CAT的運算效能,所以從根本上就會促進CAT的聲音水準,而且應該至少有DETERMINATE JITTER變小與訊躁變小的優點。因為我長期的經驗,RIP水準越高的就是播放水準越高,而且兩者幾近若且唯若的緊密關係。因此這次CUDA RIP的成功,會讓我非常相信CUDA在播放上有效!!.... 因為RIP的結果完全相同(BIT PERFECT?) ,僅僅把CAT的工作分擔給CUDA就可以得到如此強大的 RIP 差異,這對於未來的CAT播放一定有全新道路。
但是,增加了CUDA效能同時也加重了CAT本身的電力負擔與太多電子零件,上述的優點能留下多少不無疑問。而CUDA本身的運算效能,一定得透過軟體最佳化才有可能達到最高效果。JPLAY早就利用CPU的雙核或多核,獨佔且鎖定一核專用於JPLAY了。所以如果JPLAY支援把鎖核的功能鎖在CUDA時,我們大概就要乖乖玩CUDA了.....
而HQPLAYER程式本身大概可以放棄了,之前測試CUDA就覺得聲音加料,這次RIP測試後更確定HQPLAYER的聲音理念與我不合;BIT PERFECT也許不是重點,JPLAY的 STREAMER引擎也是BIT PERFECT,但是聲音與我的要求完全天差地遠呢!我認為這些播放程式的作者,還是得依他自身的音響美學進行程式寫作。所以理念與我不合的播放程式一聽就知道有底了。但是幸好證明不是CUDA有問題,而是HQPLAYER有問題,這可是大事一件!.....
如果不要求CUDA的效能(只要GT730甚至210就夠用?),只是讓CAT的工作可以分擔到CUDA就足以從而提升整體性能,那麼CAT播放應該又有大改善了。猜想下次 JPLAY "7"大概就是支援CUDA?.....
-
The Following 3 Users Say Thank You to psycho For This Useful Post:
-
2016-07-23, 04:25 PM
#2939
教授這個思維,最好JPLAY作者能看到!
JPLAY若真能支援CUDA Offload,那豈不等於在單機上完成雙機的任務,又能免去中間網路的瓶頸,一舉數得。
-
-
2016-07-23, 07:31 PM
#2940
 作者: psycho
[恕刪]
但是,增加了CUDA效能同時也加重了CAT本身的電力負擔與太多電子零件,上述的優點能留下多少不無疑問。而CUDA本身的運算效能,一定得透過軟體最佳化才有可能達到最高效果。JPLAY早就利用CPU的雙核或多核,獨佔且鎖定一核專用於JPLAY了。所以如果JPLAY支援把鎖核的功能鎖在CUDA時,我們大概就要乖乖玩CUDA了..... 
教授,GPU是用來分擔CPU計算,無法完全取代CPU,所以「鎖核」這件事情,用在GPU上是沒有意義的。
更進一步解釋鎖核... 鎖核應該是從P900大和小弟最先開始,在幾乎相同時間,應用在CAT上。
一般大家都認為鎖核是為了讓音樂播放有最大資源可以使用,所以聲音變好。
當然這個理由是正確的,但其實鎖核在音樂播放上有更多更深層的意義。
其中一個最重要的原因,也是小弟一開始決定要鎖核的理由,是時脈。
電腦內有許多種可以用來當作系統時脈的時脈源,在當時的CAT界普遍認為,HPET(high precision event timer)是最適合CAT的時脈源。
但其實更適合CAT的時脈源是TSC (time stamp counter)。
因為TSC的時脈頻率比HPET高很多(CPU的頻率 vs. 10MHz)。
也就是CPU跑什麼頻率,TSC時脈就是什麼頻率。例如CPU為3.2GHz,TSC時脈頻率就是3.2GHz。
除了頻率高這個優點以外,另一個最大優點就是呼叫TSC所使用的系統資源遠遠低於呼叫HPET,也因此呼叫的延遲快了一個數量級。
頻率高和低延遲,對音樂播放絕對有極大的幫助。
但是TSC的缺點有二:
1. 頻率不準(請注意,是不準,不是不穩),也就是本來應該是3.200000GHz,但是實際上卻為3.199995GHz。
所以如果使用TSC來做為系統時脈,系統時間可能在一天內就誤差了好幾秒。
如果沒有做網路校時(NTP),對於一般用途的電腦使用者可能會有不小的困擾。
2. 每個CPU核心的頻率都會有一點點不同,所以其TSC的頻率也會有出入。
如果相關的程式在不同的核心執行,就可能會因此發生問題。
所以TSC通常有設計每隔一段時間將不同核心的TSC同步。
然而在同步的時候,就會影響TSC的穩定度,並且會增加TSC的系統資源使用率。
這對音樂播放來說,明顯是個缺點。
對CAT來說,時脈穩定度的重要性遠遠大於準確度。所以TSC的缺點1,其實根本沒有影響。
而缺點2,就必須要解決了。
小弟的解決辦法,就是先將TSC的同步機制取消,然後把跟音樂播放相關的程式全部鎖在相同核心裡,使用相同的TSC時脈。
其他跟音樂播放無關的程式,就使用另外一顆核心。
這樣就算是兩顆核心的TSC時脈不同,不需同步也不會有任何影響。
以上才是小弟一開始想到要切割核心的理由。
從P900大之前的文章來看,小弟猜測P900 CAT切割核心資源應該也是基於類似的理由
(小弟如果沒記錯,P900 CAT大約在同時將BIOS內HPET的建議設定值從ENABLE改成DISABLE)。
ps. 基於上述理由,在超過雙核的環境底下(例如四核),將超過一核心切給音樂播放程式,很有可能聲音會比不上只切一核心給音樂播放程式。
 作者: psycho
[恕刪]
如果不要求CUDA的效能(只要GT730甚至210就夠用?),只是讓CAT的工作可以分擔到CUDA就足以從而提升整體性能,那麼CAT播放應該又有大改善了。猜想下次 JPLAY "7"大概就是支援CUDA?..... 
小弟前一兩篇文中有提到,只要將JPLAY透過NVidia介面(好像叫做NVidia控制台)來執行,就會讓JPLAY內能使用CUDA的函式交給GPU來處理了。
不需要等到JPLAY支援CUDA。
反過來說,如果JPLAY透過NVidia控制台來執行,聲音沒有變好,GPU的使用率也完全沒有增加的話,
就表示JPLAY根本不需要GPU來運作,以後也很難會有支援CUDA的JPLAY (除非JPLAY想要加入非bit-perfect播放的能力)。
此篇文章於 2016-07-23 09:55 PM 被 bchsieh 編輯。
-
The Following 6 Users Say Thank You to bchsieh For This Useful Post:
發文規則
- 您不可以發表新主題
- 您不可以發表回覆
- 您不可以上傳附件
- 您不可以編輯自己的文章
-
討論區規則
|