兩聲道
CD機 | MD機 | SACD機 | DAC | CAS | 合拼擴音機 | 前級擴音機 | 後級擴音機 | 接線 | 喇叭線 | 揚聲器 | 耳機 | 耳機擴音機 | LP產品 | 膽機產品 | 開卷式錄音機 | 音響配件 | DIY音響 | 電源 | 家庭影院
電視機 | 投影機 | 錄影機 | DVD影碟機 | Blu-ray影碟機 | 多媒體播放器 | 機頂盒 | 多聲道擴音機 | 多聲道揚聲器 | 多聲道影音組合 | Mini音響組合 | 重低音揚聲器 | 輔助設備 | 同好會
同好會 | Accuphase | B&W | Burmester | Denon | Jadis | KEF | KRELL | Luxman | Marantz | Nuforce | OPPO | Pioneer | TEAC | WEISS | News
News | Blog | 其他
其他 | 所有 |
| 影音天地主旨 ﹝請按主旨作出回應﹞ 上頁 下頁 首頁 尾頁 | 寄件者 | 傳送日期
|
| [#341] 最蠢的CAS no matter optical extender or toslink you need a very good electro optical converter, otherwise conversion jitter would be a problem ----- i don't think so. with firewire it is digital data transfer problem. |
Not-So-GoodSamaritan 正式會員210.xxx.xxx.97 |
2010-03-18 16:29 | |
|
|
|||
| [#342] 最蠢的CAS 在現實中, Real Time OS/RTP 隨處可見, 火車地鐵, 港交所, 馬會, 甚至電話, 電視, 機場控制塔. 遠至火星 Robot, 一樣有用, 經驗所見其實非常難寫. Digital 音樂播放 real time 之餘非常 time sensitive, 非常難搞. 搞不好很容易 pop/click 或衰聲, 所以較現實是用 External clock sync 去解決 Transport/ DAC 之間 data transfer 的問題. 至於用 AES, Firewire, USB, Coaxial 定 Optical, 理論(尤其係廠家講既)實係無敵, 臨場較量則需靠耳朵 blind test 分別好壞. 最後修改時間: 2010-03-18 19:34:45 |
appleteapot 正式會員 116.xxx.xxx.33 |
2010-03-18 19:31 |
| [#343] 最蠢的CAS 就算 cplay, 差不多約 60 個 version, 每個 version 都有 sound quality 分別. 莫講 cplay vs Foobar vs Wavelab vs Samplitude 等, 點會無分別? |
appleteapot 正式會員 116.xxx.xxx.33 |
2010-03-18 19:40 |
| [#344] 最蠢的CAS 至於用 AES, Firewire, USB, Coaxial 定 Optical, 理論(尤其係廠家講既)實係無敵, 臨場較量則需靠耳朵 blind test 分別好壞. -------- may be, may be not. for firewire there is slightly more than just theory. if you look at the AES paper from TC applied technologies, it might give you some objective evidence to support their claim. the firewire interface used by Wesis or Mytek is provided by TC applied technologies DICE chip. as far as i can tell from the info, the DICE uses the isochronous mode for data transfer between the pc and DICE and not the asychronous mode. so there is no data correction. there is still a possibility of data error although the error rate is in order of 10E-12. it is good enough for me. so it is not the same as firewire harddisk whereas data integrity is more paramount. but still it is data transfer problem from pc to firewire dac. the jitter problem comes in when the DICE chip interface with dac. this is handled by the JetPLL technology from DICE. is it perfect? probably not but what is! |
Not-So-GoodSamaritan 正式會員 121.xxx.xxx.33 |
2010-03-18 20:15 |
| [#345] 最蠢的CAS Are you referring to this diagram? I was kind of confused as it has both async and sync. Async data goes to ARM chip, Iso Sync data goes to 1394 but it is clocked by external clock. So looks like the Dice system supports both sync and async, depends on implementation?  |
appleteapot 正式會員 116.xxx.xxx.33 |
2010-03-18 20:34 |
| [#346] 最蠢的CAS I was kind of confused as it has both async and sync. ----- yeah! it is not too clear. however i think the async is referring to the control. i can't find any reference in the user guide of the DICE in setting any mode. the only reference is a 512x32 buffer. it is kind of small for data communication. the rest of the doc talks only about isochronous mode. but bear in mind that asynchronous mode has a specific meaning within the firewire context not necessary the same as asynchronous mode we refer to generally. |
Not-So-GoodSamaritan 正式會員 121.xxx.xxx.33 |
2010-03-18 21:02 |
| [#347] 最蠢的CAS 明白哂謝謝 Samaritan 兄! Let me search further on the Async mode of Firewire to see if the control protocol only is Async in 1394. I was wondering (1) If async then why only 63ms latency (2) If isosync then why Weiss 實牙實齒話 async mode 最後修改時間: 2010-03-18 21:46:22 |
appleteapot 正式會員 116.xxx.xxx.33 |
2010-03-18 21:40 |
| [#348] 最蠢的CAS async mode is for data flow control in communication to avoid "buffer full" and "buffer empty" situation. Product sales will tell you that it is the greatest invention in computer audio. But put it this way, if your dac has "buffer full" and "buffer empty" issue, you will hear "click" sound just like CD "jumping line" when there is missing data. If a dac (without async mode) do not have "click" sound. That means there is no buffer full/empty problem. Then the performance would be determined by other design factors. Whether it is async/sync communication would not be matter. I have no doubt async mode improve data communication and reduce buffer error. But I just cannot see a direct relationship of async/sync mode and sound quality. |
musimusi 正式會員 219.xxx.xxx.158 |
2010-03-18 21:43 |
| [#349] 最蠢的CAS the term "async" is in fact quite tricky ...... regarding the DICE solution, that async data from the block diagram only refer to any data except the real payload (ie. your audio data), this includes anything that is essential to set up communication between your PC and the DICE chip. in most application using DICE, the DICE chip is being "master" while your PC (or the device driver) is always the "slave", so some people might interpretate this as async mode operation. apart from transfer mode, another key issue is how the audio master clock is being generated or derived. it's another story..... :-) |
mdlover 正式會員 219.xxx.xxx.227 |
2010-03-18 22:35 |
| [#350] 最蠢的CAS and i think cPlay is not only a player software but a DSP engine. so that is the reason why it might sound quite different between different releases. my preferred player should only do a "read and move" operation. :-) |
mdlover 正式會員 219.xxx.xxx.227 |
2010-03-18 22:44 |
| [#351] Firewire..... ＞ If isosync then why Weiss 實牙實齒話 async mode Quote from last weekend: A chuck of data is sent from firewire to DAC using isochronous mode. The firewire itself completely taking care of the bandwidth requirement for QoS (quality of service). No matter the output is 2ch - 24/192 or 40ch - 24/96, the bandwidth is secure, stable and enough.....When exactly the chuck data is sent from computer to the DAC and the speed (faster or slower) is controlled by DAC internal master clock. This command is under asynchronous Mode of Firewire. We have papers for those: - http://www.asiaweiss.com/main/?p=492 - http://www.asiaweiss.com/main/?p=494 ＞ is it perfect? probably not but what is! Quite sum up to what actually going on....... ＞ Async mode of Firewire to see if the control protocol only is Async in 1394. Most do....MH Lab, Apogee, Mytek....but same direction, different design, different results. If objective enough to look at this area, then even the digital connection has is far from perfect, you can still design a great method to reduce jitter before it reaches the real DAC section. The Naim DAC uses a very fast DSP calculation to work in a PLL in order to set a very low corner freq, which is a good proven text book design. This goes back to the starting point that looking at just one area will not get the whole picture. ＞ electro optical converter May I just point out Chiron Glass1: http://www.weiss-highend.ch/chiron/index.html ＞But I just cannot see a direct relationship of async/sync mode and sound quality. Absolutely, we are more concern on the analogue output driving capability, high speed digital circuit interferences with amp stage, especially in a small box......but no doubt this is a better method to connect with computer. There are other issues, e..g the DICE is very sensitive to the digital eye pattern, the layout of clock path, power and sync accuracy etc. ＞ how the audio master clock is being generated or derived. it's another story..... :-) Absolutely, this is going better. ＞cPlay is not only a player software but a DSP engine Do you mean it processes the data output? That sounds scary. ＞ my preferred player should only do a "read and move" operation. :-) More interestingly that I was told by one software manufacturer that how the data "read and move" will affect the quality. |
DWS 正式會員 219.xxx.xxx.43 |
2010-03-18 22:59 |
| [#352] Firewire..... "When exactly the chuck data is sent from computer to the DAC and the speed (faster or slower) is controlled by DAC internal master clock. " I don't think DAC internal master clock is design to control when and how fast the PC sending data. It is best to have master clock ONLY use to control how fast DAC move data from memory (buffer) to DAC chip for processing. There should be another circuit to detect the buffer status and control the communication with the PC to make sure that the buffer is never empty. Having firewire communication controlled by DAC internal master clock is unfortunately misleading. And I have listened to Weiss DAC2. And it happens to have "click" sound occasionally. I do not own one. But the owner admit that he is still trying to eliminate it. While I believe firewire is good. But the implementation of DAC2 has room to improve. DWS comment on cplay that: "Do you mean it processes the data output? That sounds scary." "cplay can do DSP" is not something scary. Don't understand your point. Many players can do DSP. It is important that you can control the player so that if you want just "read and move", it do exactly "read and move" without enabling any DSP. Amarra can do DSP also. However, I don't think you will be scared by Amarra. You don't need to worry about cplay hurt your business. Those using cplay will not use Amarra and vice versa. 最後修改時間: 2010-03-19 01:06:16 |
musimusi 正式會員 203.xxx.xxx.212 |
2010-03-19 00:39 |
| [#353] Firewire..... And I have listened to Weiss DAC2. And it happens to have "click" sound occasionally. I do not own one. But the owner admit that he is still trying to eliminate it. musimusi hing,First time I heard "click" sound reported with DAC2. Can you tell me more the setting of the PC, software and connection during your audition? do other C hing in this forum of this kind of "click" sound problem? |
batmanames04 正式會員 114.xxx.xxx.26 |
2010-03-19 09:18 |
| [#354] Firewire..... thanks musimusi, I shared similar experience when I used very cheap 3 metre firewire cable ＜$40 with my INT202, the sound was still great when I turned on max buffer in my CHORD DAC, but it happened to have "click" sound occasionally. At the beginning, I just wondered my Atom based HTPC was not fast enough to process all the data. Later, when I bought a better firewire ~$88, I hear no difference in sound quality, but then no such "click" sound anymore :) That's why I think I will buy the Granite / GoldX firewire to enhance the reliability but not the sound quality. And I think the internal master clock of DAC / interface really plays a very important role. 最後修改時間: 2010-03-19 09:29:49 |
athensc 正式會員 218.xxx.xxx.18 |
2010-03-19 09:28 |
| [#355] Firewire..... ＞Those using cplay will not use Amarra and vice versa. msuimusi hing, I don't intend to bring up the software you mention. ＞ "cplay can do DSP" is not something scary. Don't understand your point. If you do not understand my point, why do you interpret my comment in such way? ＞ Many players can do DSP. It is important that you can control the player so that if you want just "read and move", it do exactly "read and move" without enabling any DSP. Thank you for explain this further. This means cplay CAN perform just "read and move" audio data, this is a good thing. I agree it is important that you can have this. I said earlier that it sounds scary when a program cannot be controlled and processes the data output. This includes the whole OS environment. ＞ And I have listened to Weiss DAC2. And it happens to have "click" sound occasionally. I do not own one. But the owner admit that he is still trying to eliminate it. User is always welcome to contact us for assistant if needed. I think it is logic that if there is problem, you contact with the people who made that product. ＞ Granite / GoldX firewire to enhance the reliability but not the sound quality Indeed that is the point. I get most people missed my point somewhere Daniel Weiss and I looked out for some cables that is suitable for our firewire connections, here are some of them: They are double or triple shielded which is good. http://www.tripplite.com/en/products/product-series.cfm?txtSeriesID=108&EID=35 http://www.tripplite.com/en/products/product-series.cfm?txtSeriesID=99&EID=35 When you have click sound on MAC platform, you can change the operation mode from "normal" to "safe mode 2 or 3". If you have PC platform, it is even better than you can turn on the DPC checker and it measures your DPC latency live, and suggest which operation mode to choose for. You can change the PC buffer size too. Usually the DPC latency tells you what happens on your computer or conflicts between the firewire chipset and other devices such as graphic display. |
DWS 正式會員 219.xxx.xxx.43 |
2010-03-19 10:10 |
| [#356] Firewire..... DWS commented: "＞Those using cplay will not use Amarra and vice versa. msuimusi hing, I don't intend to bring up the software you mention. " I like this point. In fact, you may from now on stop bring up Weiss product discussion in R33 forum as well. I'd very much appreciate that. 最後修改時間: 2010-03-19 22:56:28 |
musimusi 正式會員 203.xxx.xxx.212 |
2010-03-19 22:54 |
| [#357] Firewire..... 不覺得 bring up Weiss product discussion 有甚麼問題? 咁 Bring up Benchmark 得唔得? Bring up Chord / JM Lab 得唔得? Lynx 得唔得? Asus 得唔得? Sound Blaster 得唔得? 只係有些 vendor "許讚不許彈" 的態度, 都算了. 反而是那些踢爆後發爛 ja 的態度要不得. 最後修改時間: 2010-03-22 09:12:42 |
appleteapot 正式會員 116.xxx.xxx.33 |
2010-03-22 09:12 |
| [#358] Firewire..... i think there are misunderstanding between c hings, please continue discuss this topic |
batmanames04 正式會員 114.xxx.xxx.221 |
2010-03-22 09:44 |
| [#359] Firewire..... 茶壺兄 如果我無意會錯 musimusi兄應該是講反話 疾vendor 所以他應該是支持繼續討論 |
fishjai 正式會員 219.xxx.xxx.75 |
2010-03-22 10:56 |
| [#360] Firewire..... ＞＞＞..cplay will not use Amarra and vice versa That's true since cplay only support Windows OS. But then, it is interesting to know any Weiss dac user using Windows OS for dac2/Minerva like me ? ＞＞＞..臨場較量則需靠耳朵 blind test 分別好壞 No offense, but appleteapot, you said what I dare not to say for months.... ^__^ |
Vash 正式會員 203.xxx.xxx.79 |
2010-03-22 11:32 |
