Hiendy.com 影音俱樂部

 找回密碼
 新用戶註冊
搜索
熱搜: hifi av 音樂
查看: 11262|回復: 36

[分享] DCS 的缺陷美

[複製鏈接]
發表於 2019-3-14 00:26:03 | 顯示全部樓層 |閱讀模式
本帖最後由 Egypt 於 2019-4-2 15:59 編輯



DCS 這品牌近乎每一個發燒友也喜愛,我也不例外! 我第一次擁有的是 Network Bridge,初嘗的感覺非常好,晚上駁著後,不停找心愛歌曲播,越播越大聲,越夜越精神,直至凌晨三點被管理員拍門才收場。


671C8B82-46F2-4B17-8EC7-D2FE26389FFE.png
開心背後總帶著點點煩惱。當你花盡心思怎樣優化每一環節,力求達至極致時,竟發現最基本操作介面“ Remote ”問題多多。想像不到一個名列 Hi End 界之首,擁有全球不少音樂迷,能出一個如此拙劣的 App?! 
起初以為是我未熟練操作之過,所以花更多時間了解研究。越玩,感覺越差,越試,更感到設計花了心思但有很多不足!! 這結論不是我個人睇法,是我認識眾多 DCS 用家的感覺,無一有異意,甚至有朋友破口大駡,只玩 CD 部份,CAS 部份是多餘的!App.操作極差,所以好友們請我多加研究,希望有轉機,但可惜。。。

02E7B9EC-9B15-4D0E-8CD7-4DA5845B56C4.png
DCS App. 經常不能即時睇到 photo album

D11DE4E0-6CF8-4BA3-B0A5-DC297802F254.png
實話實說,如無其他App.選擇,相信 DCS 的銷量少了一群玩 CAS 的發燒友(包括我)。曾email 給英國 DCS 查詢,DCS 一方很有禮貌,也給了不少寶貴意見,但奈何他們鼓勵我用 Roon , 在網上聽到不少 Roon 的介紹,強項是資料搜尋詳細,multi zone remote 厲害,DSP 功能強大等等,提到 DSP 方面,DCS 官方建議 turn off 所有功能, 即 direct through,只用 remote control and metadata 兩部份便已足夠。

68B0145D-09DB-4E82-AA67-13EFF14DB41D.png
由於 Roon Core 需求很大,聽聞大多數 NAS 也未能盡情發揮,而資料搜尋及 multi zone remote 對我來說是無需要的! 當然,Roon 也有一定 Fans 支持,有些朋友話很有 analog feel , 也有老友話用了感到很電腦聲,因此我會試裝感受一下,世界沒有完美的事,如好處多於缺點,何不轉陣追隨?反之,一個實用的 Remote App. 已足以滿足到我了(我要求很低),試問一部器材的 Remote 表現拙劣,豈能發揮器材的能力及潛能呢?! 當然,任何可令音色提升的方案,我也願意追隨及關注。

8A8E5361-6178-4EA8-A821-18979E0BEDEA.jpeg
DCS App.                                LUMIN App.


曾用過不少 Control App.,以 Lumin App.操作最為全面,可惜用 Tidal 時,經 Bubble App.只限於 44.1 output,聽 MQA 當然是16/44.1。而在比較音質下,使用 DCS App. playback 44.1往往大勝 Lumin App.,確是比下去!! 再者,用 DCS App.可直接在 Tidal play MQA,更可解決 gapless 問題,所以為何我主動 email 給 DCS,希望 DCS group 能投放多些資源及心思於自己 App.上,不要讓一小缺陷而影響這美妙音樂及畢生的美譽。這也是發燒玩家所追求極致的!

49982EE4-B338-4DCD-B266-92390E415262.png
LUMIN App.

10AB44A1-219B-4F9E-B6AB-867DC897BEB7.png


https://www.facebook.com/Rames.Labs/





評分

5

查看全部評分

發表於 2019-3-14 00:34:11 | 顯示全部樓層
dCS 的 app 確實不足。


用 Roon 喇,好好聲。
發表於 2019-3-14 00:45:10 | 顯示全部樓層
叫餅主搞番個Roon團購
發表於 2019-3-14 00:47:58 | 顯示全部樓層
vhs 發表於 2019-3-14 00:34
dCS 的 app 確實不足。

dCS app都係Roon做,但dCS app比 Roon 好聲,但Roon UI實在係好正,直得投資
 樓主| 發表於 2019-3-14 01:14:00 | 顯示全部樓層
Sa683s 發表於 2019-3-14 00:47
dCS app都係Roon做,但dCS app比 Roon 好聲,但Roon UI實在係好正,直得投資

如DCS App. 是Roon 設計,那就確是有所留力
發表於 2019-3-14 01:21:51 | 顯示全部樓層
本帖最後由 vhs 於 2019-3-14 01:35 編輯

Roon 除了介面非常好之外,也用了自家 RAAT 來傳遞 music data。小弟也比較過用 dCS app 在 network 上 取 music data 來播放,用 Roon 是比較好聲的。

Quote from Brian Luczkiewicz (Founder/CTO at Roon Labs):

"So the first thing to understand is–RAAT is very different in design goals and scope than the other protocols. Some of the other protocols have some of these other goals, but as a general rule, we are concerned a lot more about the end-to-end user experience than the people making the protocols you asked about–they are building infrastructure, and we are building product.

You may be thinking “but I asked about the technology” and yes I will get to that–but looking at RAAT as a streaming technology in isolation is missing important context. RAAT isn’t just plumbing–it’s a product that executes on the goals stated above.

From a user experience standpoint

It’s almost not worth comparing RAAT with the others. They don’t solve the quality assurance problem. They don’t create a consistency of experience. They don’t handle out-of-band concerns like volume control or standby or convenience switching without out-of-band extensions (like what Merging have done on the NADAC). They don’t work on WiFi, …

On a technical level

To fully extract the benefits of AES67/DANTE/RAVENNA, you need a well-engineered ethernet network, and controlled computing environments on the sending/receiving side.

In return for that, you get low latency capabilities and extremely scalable matrix mixing. This is important for some applications, but most homes (meaning, 99.99%) are not large enough to need unlimited matrix scalability and most music listening does not require low latency. With RAAT, we’ve made a different set of tradeoffs. We’ve sacrificed some things that are not so important in return for properties that are better for our application.

AES67+Friends are streaming in real-time through a relatively small fixed-sized buffer. Maybe 1ms, maybe 500ms–pretty short either way. Packets are sent in real time. When you press “pause” you wait for the buffer to drain. When you press “play” you wait for the buffer duration to pass before hearing anything. The protocols behave sort of like a speaker cable with a built in delay.

RAAT is different. When you press play, Roon blasts a couple of seconds of audio into a buffer on the endpoint as quickly as possible. Often this can be done in just a few milliseconds, since computers and networks move faster than audio streams. Then playback starts, and Roon continues filling the endpoint buffer in a faster-than-realtime manner until it is full (currently that means 10 seconds of audio in the endpoint).

Once playback starts, the endpoint drains this buffer using its own playback clock, and Roon’s job is to replace data as it is consumed. Once full, it takes a pretty large network failure to have that whole 10 second buffer drain before it can be replenished.

Of course, you wouldn’t want to pipe TV Audio through a buffering scheme like this. But for music listening, streaming latency doesn’t matter because we are free to pre-fetch data out of your files–and we can solve user experience latency while keeping our large buffer sizes by buffering faster than real time, so even though we have 10 seconds of buffer in the chain, playback still starts in a few hundred milliseconds or less.

Why the huge buffer? Because it makes RAAT stable on networks that were not installed by professionals, including WiFi networks.

Compared to the other protocols, RAAT is a lot more involved in the discipline of playback. When you press pause, we simply stop the buffer from flowing and retain the audio data on the endpoint until you unpause. With the others, the buffer drains on “pause” and then must be refilled when you unpause. This is all the result of RAAT being designed around music listening, and not simply for moving audio around.

RAAT tries to “tread lightlly” on the network. We use TCP to move the audio instead of UDP because that’s what 99% of peoples’ home network usage looks like–web pages, Netflix, Youtube, and Spotify also use TCP. So if you have a network that supports those, RAAT will probably work.

Finally, RAAT is built to evolve in place without firmware updates. This means that many of the details I described above are not actually details of RAAT, but rather details of Roon. 6 months ago, RAAT was a UDP based protocol with a 2.5 second buffer. Now it’s a TCP based protocol with with a 10 second buffer. We reworked part of the “flow” of starting a new stream a couple of releases ago because some newer WiFi devices were having trouble with the old “flow”. All of these changes rolled out without modifying any devices or having people wait for their manufacturers to “catch up”.

These changes are delivered via Roon without device firmware updates–so in that sense, RAAT is much more of a living protocol. I have some ideas about how to improve clock synchronization on high-latency WiFi networks, and how to improve sound quality during multi-zone playback. When we find the time to work on those, those will result in changes to the protocol and the benefits will roll out uniformly to all of our devices.

In this regard, RAAT is more of a vehicle for delivering Roon’s current idea of state-of-the-art audio streaming to your devices, rather than a protocol in and of itself.

In closing

RAAT is a streaming product targeted at music listening on home networks. AES67/RAVENNA/DANTE are infrastructure for moving audio around controlled/managed environments. They are really for different purposes, so they work totally differently. It’s not a matter of “better” or “worse”. Just different tradeoffs and different goals.

If I wanted to build ethernet-based matrix switching for a huge home that was going to be used for routing real-time sources like TV audio, I wouldn’t use RAAT. If I want to stream music and internet radio to the WiFi speaker in my kitchen, the other protocols wouldn’t even be an option."

End Quote
A2A38ED3-45A6-40CD-B2A2-5CA430E235DF.jpeg
1FF1BC41-607D-4619-AAC9-284C95DA4C46.jpeg

評分

1

查看全部評分

發表於 2019-3-14 04:32:17 | 顯示全部樓層
load album arts慢純粹係因為network慢,你用2.4GHz定5.0GHz Wifi?
 樓主| 發表於 2019-3-14 06:46:54 | 顯示全部樓層
本帖最後由 Egypt 於 2019-3-14 07:06 編輯
diamondblack 發表於 2019-3-14 04:32
load album arts慢純粹係因為network慢,你用2.4GHz定5.0GHz Wifi?


5.0GHz
我用Lumin App完全無這問題
 樓主| 發表於 2019-3-14 06:55:56 | 顯示全部樓層
本帖最後由 Egypt 於 2019-3-14 07:18 編輯
diamondblack 發表於 2019-3-14 04:32
load album arts慢純粹係因為network慢,你用2.4GHz定5.0GHz Wifi?


002601j9kddsdxj2ed2ss1.png
以上blank 的photo album 你不上下移動至out of screen refresh ,它是不會load photo album ,相信這不是network problem
001022e5p2vt2uwzttps1w.png
發表於 2019-3-14 07:27:55 | 顯示全部樓層
Sa683s 發表於 2019-3-14 00:45
叫餅主搞番個Roon團購

Hi sa683s  hing,

可以找我的 for ROON
發表於 2019-3-14 07:32:01 | 顯示全部樓層
本帖最後由 blau.vol 於 2019-3-14 08:52 編輯
Egypt 發表於 2019-3-14 01:14
如DCS App. 是Roon 設計,那就確是有所留力


For lumin app,  佢地design is base on OpenHome standard,  NOT 100% UPnP / DLNA one.  and Lumin app 因為設計是比 Lumin device 用家使用 .  Command fine tuned for LUMIN U1 mini to X1 etc......

佢地由頭到尾都沒有想到要做一個 freeware 比大家用.  大家用到是開心.  用唔到 or command handshake NOT fine tune 可能沒可以辦法了.....

評分

1

查看全部評分

 樓主| 發表於 2019-3-14 08:38:50 | 顯示全部樓層
本帖最後由 Egypt 於 2019-3-14 08:41 編輯
blau.vol 發表於 2019-3-14 07:32
For lumin app,  佢地design is base on OpenHome standard,  NOT 100% UPnP / DLNA one.  and Lumin app ...


同意的。所以要經bubble 才可用Lumin app ,但操控上竟然是最好。試問用別人的app都好過你(已經不是為DCS 而設),是否好好了解用家的角度
發表於 2019-3-14 09:02:21 | 顯示全部樓層
Egypt 發表於 2019-3-14 08:38
同意的。所以要經bubble 才可用Lumin app ,但操控上竟然是最好。試問用別人的app都好過你(已經不是為DC ...

完全明白.  其實.  這與近年營商模式也有些關係呢. 內部還是外判.   Lumin 要養好多本地同事做development ,  軟件更新, 升級.  加功能等.  而另一間公司.  在這方面, 是後者.  所以有時.  會有不同的體驗......

我也有Bubble & MConnect .... 完全明白不同的用戶體驗.  

發表於 2019-3-14 09:18:14 | 顯示全部樓層
blau.vol 發表於 2019-3-14 07:32
For lumin app,  佢地design is base on OpenHome standard,  NOT 100% UPnP / DLNA one.  and Lumin app ...

發表於 2019-3-14 09:21:05 | 顯示全部樓層
Egypt 發表於 2019-3-14 08:38
同意的。所以要經bubble 才可用Lumin app ,但操控上竟然是最好。試問用別人的app都好過你(已經不是為DC ...

我用minimserver用dcs app又無乜問題。

不過,我全部files都無tag,我album arts係由minimserver認folder裡面嘅album jpg嚟派。簡簡單單。
發表於 2019-3-14 10:29:12 | 顯示全部樓層
dCS + Roon 確實方便好用,尤其你有好大的 database , 他的靈活性 flexibility 是其他 apps 未有的,所花的 life time license fee, 如果除開好多年,每年的所費好少,真正早買早享受。

評分

2

查看全部評分

發表於 2019-3-14 11:31:24 | 顯示全部樓層
C HING覺得DCS APP同minimserver.
那ㅡ個好聲D呢?
發表於 2019-3-14 12:41:35 | 顯示全部樓層
jimmyihv 發表於 2019-3-14 10:29
dCS + Roon 確實方便好用,尤其你有好大的 database , 他的靈活性 flexibility 是其他 apps 未有的,所花的 ...

同意
發表於 2019-3-14 13:08:23 | 顯示全部樓層
hpchpc 發表於 2019-3-14 11:31
C HING覺得DCS APP同minimserver.
那ㅡ個好聲D呢?


個dCS app係一個control point同player app,而minimserver係media server負責派歌,兩者唔可以咁比較。
發表於 2019-3-14 14:35:35 | 顯示全部樓層
我應該話DCS個SOFTWARE跟minimserver個SOFTWARE播FILE.
那―個SQ會好D.
您需要登錄後才可以回帖 登錄 | 新用戶註冊

本版積分規則

小黑屋|Archiver|手機版|聯絡我們|刊登廣告|Hiendy.com 影音俱樂部 一個屬於音響愛好者的家

GMT+8, 2022-7-6 22:02 , Processed in 0.045849 second(s), 18 queries .

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回復 返回頂部 返回列表