[耳機撚]召集大耳牛、枱式耳機系統用家(32)

打開volumio ssh server好簡單,睇圖



撳掣



用ssh client 輸入 volumio@local_ip, 密碼係volumio，我冇改，外網入唔到LAN嘅，冇需要



咁就可以安裝唔係volumio官方嘅plugin 或者查吓系統訊息，呢個夠電嘅

Pi 3 係 lan usb 共用嘅
Pi 4 係 lan usb 分開 controller

如果想試volumio 3 beta版，喺上圖enable ssh上面有test mode，撳掣之後去番UI，就可以通過OTA update去beta版幫手試bug，例如有冇DAC認唔到報告番

利申冇做bug tester

史前年代Mac colour profile易管理D
結果而家成班弱智當Mac機色準好D
Audio亦都係同理

講嚟聽吓點弱智法？

頭先去觀塘廣場行一轉，多左好多間賣差唔多野鋪頭（音響+電器），最少兩間有bha100
唔係好覺有kanto喇叭，可能我冇睇清楚

你唔拎colorimeter cal過既MacBook panel好難production用嫁喎
Mac既優勢係佢管唔同panel (external or internal)既colour profile容易
所以不論你去到邊到個baseline都比較易維持到
前提係 你會用既Mon已經全部calibrated
單純執部MacBook Pro就開工既結果同執部Dell/Lenovo其實就分別唔大

Audio其實都係同理
Mac既史前優勢係latency
由樂器入interface到聽到要400-500ms對創作者黎講係好大既問題黎
pre Vista年代Windows既解決方案有二
Kernel Streaming同ASIO
兩者都係為low latency而走去cut overhead既方案
然後其中一個overhead叫SRC
Vista之後多左個選擇去做同一樣野
叫WASAPI exclusive mode

SRC問題大唔大？大 但你最好check左你部DAC有冇強制升頻先
有D話你前面搞乜我都覺得係lost cause黎

Creator同Hi-fi個use case唔同
我就咁睇既
與其斤斤計較自己playback係咪用Mac
買個audio rack搞好isolation唔好係枱面層層疊
咁對聲既影響隨時重大

呢個的確係windows問題，不過裝完driver就解決到呢個我覺得ok

其實PC同Mac都係general purpose computer, 唔會幾大分別，真係追求「極致」音色（可能係可能唔係），用linux 自己搞個low latency kernel , X86 有 https://ubuntustudio.org, pi可以用 https://www.ap-linux.com 呢啲搞好咗嘅

自己可以編譯核心

https://wiki.linuxaudio.org/wiki/lowlatency_deprecated

但啱唔啱聽我就唔肯定

windows 最煩裝driver ,好多寫得唔好嘅driver 使用大量CPU資源

第一我冇MAC嘅，電腦音響就係電腦音響，咪玩玄學，你話好聽冇得駁，windows 係咪 使用CPU資源或者latency 低過MAC? 定係其他？ windows係2019年先開始有UAC2, 仲唔係個個DAC唔使裝DRiver, DAC63115就 要裝，肯定個driver 寫得好好冇問題？

https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

其實PC同Mac都係general purpose computer, 唔會幾大分別

Yes and no
的確我地上面講既野，出黎效果唔會好大分別
會明顯過rip CD，不過好似Drunktoop巴打講，可能用個好d audio rack放機分別仲大
用唔同player software個分別會明顯d

不過幾隻OS個kernel, audio core, scheduler等等個設計都唔同，呢d都決定佢個極限可以去到幾勁，可惜好似冇人有系統咁試過，呢個係一個有趣而麻煩既topic

多數做product 一定諗成本先，所以一定係linux base, 唔洗錢又多example，而唔會比較邊個OS 好d

Windows server 成本太高，就算係window base既audio server都唔會平得去邊
window base audio srever我只係識呢個
https://www.fidelizer-audio.com/nimitra-computer-audio-server/

Mac就更加唔洗講，有apple強大控制，你都唔洗諗可以改到d乜出黎，你只可以接受Apple 覺得「應該要咁做」既方法

我睇過好多DAC都要係windows 裝driver, fiio k5pro 要， dac63115要，我唔知佢個係咪標準UAC2嚟，定係同windows 系統架構有問題，廠商要特別寫driver 先用到佢嘅asio/wasapi ?

正常使用UAC2嘅DAC係咁，唔使driver

我都冇私人用既Mac喎Ching

同一個事實可以推導到完全相反既結論嫁
你點肯定Microsoft純粹睇USB Audio Class 2 spec寫既generic driver會fit過知道implementation細節既vendor寫既driver?

我既立場非常簡單
你換機轉OS既影響其實不如將D老派基本面（三大件既電同震動）處理好先
而家有部Window機就是但開下WASAPI exclusive mode照用啦

ASIO唔係Microsoft自己/open standard
Generic driver唔support正常

Mac/Linux唔洗用呢set專有API自然冇呢種問題

咁點弱智法？

我講系統唔係呢啲，搞核電水電最好聲同系統無關，點弱智法？

理論上ms嘅 uac2 driver係跟USB org 標準文件制作，廠商根據USB org 標準製造硬件，點解會多個driver?

2樓水煙個邊有
好很正

用過ifi, nmsl, sony dap其實用windows usbaudio2 driver都用到wasapi 不過如果要用asio就要裝第三方driver

最簡單解釋就係windows 會使用 software conversion ,廠商需要另外寫個driver bypass, 然後多咗asio/wasapi 呢兩個嘢迫使用硬件唔經系統software以硬件輸出

搞咁多花式不如買部M1 macbook air, 而且係冇風扇

呢個係windows design 問題，windows basic 個d driver 真係work到最基本功能就算，以compatibility為目標，唔會理個device 有冇asio
原因係Windows 個系統係太多function 但又唔係open source，即係話你個device 有d野同基本function 唔同就要用自己做driver。所以你可以講windows set 個標淮太保守，保守到近幾年先support uac2。個概念係用windows 就device
事實上，9成Winodws 用家都唔會care uac1/uac2，佢地只會想買個headset ，插入電腦就用到，而呢樣野用最基本個d功能就滿足到，Winodws 自然唔會好比心機去做呢個support

係Mac個世界就係device 就Mac，除非你唔想部機係Mac 用到
Mac有度好係佢target 工作用，所以工作用到既野都會用自己覺得好既方法做齊
所以巴打見到好似插落去乜都唔洗搞可能係咁岩你用緊個defined use case
認知當中如果player 唔support bit perfect, 都係會經SRC（好似話Mac 個SRC仲差過winodws），其實同Winodows 一樣，而且你連driver 都唔會見到，一係work 一係唔work，唔work 又唔知點解咁
當然話曬都係bsd底，識既都係會搵到個driver 去debug既，我會覺得winodws 有個gui睇下好似用得開心d

Linux 就同windows 差唔多，都係OS 就device。勝在open source, 你有use case, linux 未support，你就自己commit d code 上去
巴打見到Linux 一插就用得其實可能係前人寫好比你，用家寫比用家自然用得順手
不過因為用家都係寫比自己個use case, 所以遇到一d cover 唔到既case就好煩
記得初初買pi 2b玩個時買左隻wifi usb dongle，之前check 過呢個wifi chipset有linux driver，買到返黎pi 2b認到個device 不過裝唔到driver，冇一個driver 係pi 2b用既，又或者個kernel version/ CPU platform 用唔到。結果我幾經辛苦搵到個相同wifi chipset driver 既source code, 自己學改driver 加隻wifi dongle support，學compile 個driver，最後先可以裝到個driver 用

你係明顯唔明上述API同Driver之間既關係同埋佢地係用黎解決D乜問題既情況下做左咁多斷言
Well if you feel offended, sure.