Switch mạng + lọc nguồn cho nhạc số

e nghĩ con dCS này đủ độ tin cậy , qua switch có thay đổi , thêm FMC lại thay đổi > nay có 6 đôi tai nghe thì cũng đủ tin cậy rồi

 

Nốt cái này thì dừng.
Bác cho phép mình hỏi vấn đề đó ngưòi ta xử xý thế nào ?

bác rút cáp ra thì thấy nền âm tĩnh hơn một chút, xin lỗi bác kiếm con switch tốt hơn đi nói thật lòng, nó thay đổi khi cắm vào là vì nó bleeding jitter từ chính con switch sang đấy, thiết bị của mình khác loại các bác dùng, nên với mình rút ra hay cắm vào DAC/STreamer của mình không có sự khác biệt, nếu chất lượng âm thanh nó xấu thì nó xấu đều, nếu nó tốt thì nó tốt đều, chỉ test sự khác biệt, không nói về chất lượng âm thanh nhé

 

Đang định chơi cách ly quang cho streamer/DAC bằng Sonore opticalModule Deluxe và Uptone EtherREGEN, cấp bằng nguồn tuyến tính ngoài thì @HNE ra cái one box này hay đấy, gọn gàng. Có vỏ anode đen chưa em?

 

@bác Jacky
bữa nào ta cafe giao lưu với nhau, biết đâu học hỏi thêm được điều gì hay từ bác,

 

em dùng etherregen đó bác
Đứng trước ER có lúc em để cái sonore optical module (OM) hoặc có lúc e bỏ OM đi, tương thẳng vào router (OM chất âm gần với ẺR nên khi dùng cả 2 thiết bị này đặc tính như nhân đôi vậy)

E ko nghĩ đó là jitter vì lúc chơi từ ram thì ethernet ko streaming data gì cả, nhưng có thể nó vẫn có 1 dạng noise gì đó bị đưa vào server khi cắm dây mạng. Khác biệt dễ phân biệt nhất dải cao, âm “sss” “sh..” (sibillance) của giọng ca sỹ nó ở giới hạn của tự nhiên hay vượt quá.

ok bác, vậy mà em tưởng bác ở nước ngoài chứ!

 

dạ , mẫu này e lại chỉ có mỗi vỏ trắng a ạ

 

Giờ mình làm việc cho môt hãng ở US, hiện mình đang làm việc remote, trước COVID mình đi về 6 tháng một lần, từ hồi tết 2020 đến giờ mình ở Sài gòn và làm remote chưa biết bao giờ mới qua lại bên đó. cso gì PM cho mình số phone của bác nhé.
Thôi bỏ qua mấy cái tranh luận nếu bác thấy mình võ đoán hay bảo thủ nhé, vui vẻ là chính thôi

 

Em thích câu bác chưa edit hơn :” ...không có sự khác biệt lớn như vậy” đó mới là mấu chốt vấn đề.

 

Thôi bỏ qua chuyệnnày, mình cũng không đủ tiền để mua và đổi hết đồ âm thanh này đến đồ khác đẻ trải nghiệm, chỉ là ghi nhận trên hệ thống hiện có, mình chỉ là dùng một nhãn hàng đồng bộ tất cả các stacks trong cùng hệ thống với nhau, đơn giản là mình trước cũng có hí hoáy với vài món mua nhỏ để kiểm chứng nó có đúng như lý thuyết không mà thôi, cái này thì bàn qua bàn lại cũng chẳng đi đến đâu vì nó có khá nhiều factors làm thay đổi đến kết quả. (seriously) kết quả sẽ không consistent toàn thời gian.Xây dựng được tập dữ liệu làm đầu vào để test và benchmark một hệ thống trên thực tế không phải dễ và chứng mình được tính đúng đắn toàn thời gian được

 

bác thử cho mình việc rút dây ethernet ra nhé.
Nếu đó chỉ là trải nghiệm của mình thì hệ thống networking của mình vẫn đang có vấn đề đâu đó.

 

MÌnh không dùng music server như trong cấu hình của bác, trước mình dùng DirectStream DAC của PS với network card II, mình không thấy sự khác biệt giữa con RE và con Ubiquiti/ Cisco, Juniper mình đã dùng, vì con DS của mình là bit perfect rồi.bản thân trong nó đều có galvanic input stages. Không khác biệt trên cùng một đoạn nhac được lặp đi lặp lại từ giây thứ 30 đến 45 của một track được stream qua RE và ngắt khỏi mạng. mình repeat cái test này không dươi 30 lần dùng một tráck duy nhât mà mình nghe hàng tẳm lần đến nối nó in vào não cái sân khâu âm thanh và các tiếng guitar dạo đầu sắc lẹm và căng mọng. Mình quen thuộc với cái track này đến mức nhắm mắt lại cũng tái hiện được nó.

Anyway, không bàn về sự hay dở âm thanh của một dàn ở đây, chỉ là có hay không sự khác biệt.

Đó là kết quả của mình nếu bác quan tâm.

 

Nhân tiện mình thấy cần bổ sung thêm chi tiết về thiết bị âm thanh của mình dùng để test. Do đặc điểm là con DirectStream Dac của mình nó upconvert tất cả đầu vào lên DSD 256 để lọc nhiễu và làm sạch sau đó mới chuyển về PCM và xuất qua mạch analog, nên không còn hiện tượng nhiễu trên đầu vào của các input stage, khoan nói đến tính chất âm nhạc đầu ra của quá trình này là hay/dở, vì gu nhạc của mỗi người là khác, cái bridge audio network card II của DS Dac là loại galvanic isolation và bảo đảm bit perfect nên minh dám tự tin khẳng định mấy con audio sw các bác đang thử không có tác dụng với mình, EtherRegen là một phép thứ mình đã làm. Thiết bị tầm trên 5K chắc chắn nó sẽ phải khác hơn loại 1-2K hoặc rẻ hơn, nhà sản xuất không phải là không ý thức những chuyện chúng ta trao đổi, họ thậm chí còn rõ hơn cả chúng ta về vấn đề này, tuy nhiên mỗi giải pháp dù hiệu quả đến đâu cũng sẽ phụ thuộc vào mức độ đắt và cao cấp của sản phẩm làm ra.

Mình phải nói thêm điều này vì nếu không có gạch đầu dòng ban đầu để thống nhất hệ quy chiếu, ta khó có thể thống nhất về cách nhìn, có thể lệch trọng tâm trao đổi vì điều kiện đầu vào, hệ thống thử nghiệm khác nhau.

Thân

 

Directstream Dac nó tự chơi bufer và offline được lâu thế cơ hả bác?!?
Nếu e k dùng server mà dùng DCS bartok dac để stream trực tiếp qua app của nó thì rút dây ethernet ra chỉ chơi đc vài s là mất, do đó ko đủ thời gian để đánh giá. Ethernet input của dcs em tin là cũng tốt trong thị trường rồi.

 

Bridge Audio network Mark II dùng trong DS DAC nó buffer cũng khá, cũng khoảng gần 10 giây trước khi tắt tiếng, mình rút ra và cắm lại trong khoảng thời gian 7 giây, vì là kết nối TCP nên sau 3 giây uplink nó sẽ truyền lại, trên switch phải set mode RSPT ON (rapid spanning tree) lên để nó move port sang trạng thái forward ngay, nếu không sẽ mất gần 30 giây để move từ blocking -> learning -> fowarding để traffic có thể truyển lại.

DCS Bartok DAC của bác thuộc phân khúc cao cấp rồi, không cần bàn về chất âm, tính năng và chất lượng linh kiện nữa chỉ là gu nghe của mỗi người thôi, DAC thông thường chỉ buffer được trong khoảng 5 giây với bộ nhớ 16K trên ethernet module (loại thường tốc độ 10/100mbs với MTU size = 1500 byte), vì dưới 3 giây ngắt kết nối, TCP connection sẽ waiting trong vòng 3 giây sau đó bắt đầu truyền lại chứ không bắt đầu lại quá trình handsaking nữa, đó là lý do các buffer trên ethernet module thường chỉ buffer dữ liệu dưới 5 giây. ở mình nó lâu hơn chút là do bản thân con DS nó có bộ nhớ khá lớn, mọi đầu vào nó đều upscale lên DSD256 rồi mới chuyển đổi về PCM, do FPGA của PS dùng nhiều mảng 8 bits/channel (16 channel) để upscaling các input sources và dùng nội suy tuyến tính, nên một lượng lớn dữ liệu cần phải được buffer sẵn trên bộ nhớ để đồng bộ với tốc độ xử lý của FPGA, nó chơi được lâu khi ngắt mạng là do nó chơi từ bufer trên DS DAC thôi chứ không có gì khó hiểu.

Trên thực tế nhiều hãng đã bắt đầu support long queue buffering cho stream nhạc có độ phân giải cao, mục đích là tạo ra không gian lưu trữ lớn hơn để sắp xếp lại các ethernet frame và retransmision các packet loss theo cơ chế TCP oriented connection và đồng bộ với tốc độ làm việc của các khối DSP, DAC có dual chip thì buffer con lớn hơn loại 1 chip.

NAIM DAC thường có độ dài buffer gần 2 phút với file PCM 16/44.1 là một ví dụ. Ngoài con DS DAC ra, con Cambridge Audio CXN V2 của mình nó cũng buffer được gần 30s khi ngắt kết nối, chơi DSD qua DoP thì chỉ còn lại gần 10 giây.

Các giao thức streaming nhạc/phim ngày nay luôn sẽ buffer dữ liệu và truyền trên hàng đợi theo cơ chế FIFO, bản chất nó không phải là livestream nên nó cần phải nhồi dữ liệu đi càng nhiều càng tốt. tại đầu nhận cơ chế kiểm tra sẽ được tiến hành dựa vào sequence number và checksum của gói để bảo đảm tính toàn vẹn dữ liệu và yêu cầu truyền lại gói bị mất dựa vào sự gián đoạn của sequence number. Về cơ bản một con switch sẽ cần phải trong suốt và bảo đảm chuyển phát đúng dữ liệu từ nguồn gốc mà không can thiệp vào gói tin.

Mình dùng TiDal để stream một track có độ dài 7 phút và nhận thấy nó buffer cái track đó về sau khoảng 30 giây và bắt đầu play ngay sau giây thứ 3 khi bắt đầu buffer, quá trình buffer diễn ra đồng thời cho đến khi nhận đủ cái track đó, tren DAC dữ liệu được nạp lên bộ nhớ trước khi đổ vào mạch D/A , rút cáp ra hay ngắt kết nốt wifi nó vẫn chơi bình thường, cả nửa bài nhạc hoặc hơn.

Bác thử lên youtube nghe bài nhạc rồi ngắt kết nối, nó sẽ tiếp tục chơi khá lâu sau đó. Giao thức streaming implement theo RFCs là như nhau và áp dụng chung cho các thiết bị stream nhạc, dù là hi-end hay low-end. Nghe hay/dở lại là câu chuyện khác.

 

Mình đọc manual thấy con dCS của bác có 2 port ethernet đều là galvanic isolation có khả năng miễn nhiễm với nhiễu từ cabling, có thể hỗ trợ LACP (IEEE 802.3ad) và nhiều thứ khác cần port thứ 2, bác thử config nó thành một interface thôi và cấu hình trên switch của bác hỗ trợ LACP, sau đó nghe thử xem có khác biệt gì không. Hãng làm ra 2 ports là có mục đích cả, còn nếu không test được thì có lẽ cái port 2 chỉ là cái network loop dự phòng, cần phải có expansion card thứ 2 cắm vào mới hoạt động được

 

bác @Leean
cái port network loop thì user manual nói là để dùng cho tính năng tương lai nên em chưa động vào bao giờ.
Cổng main network là galvanically isolated nhưng thực tế là nâng cấp mạng vẫn nghe thấy khác biệt, thay cái dây ethernet zin theo máy cũng khác biệt nốt đó bác.

 

Trong audio tối kỵ nhất là buffer và check lỗi đường truyền sẽ làm tăng độ trễ (latency) không còn realtime. Vì sao linux được ưa chuộn cho audio? Chính vì realtime này.

 

@oneclicklogin

Phát biểu quá ngắn của bác khiến em thấy hoang mang và bối rôi tột độ
Check lối đường truyền thì nó xảy ra trên end to end mà, latency là thời gian của packet đi từ A->B theo kêt nối point-to-point, dù có truyền đi truyền lại hay không thì nó chỉ là tổng số packet được truyền thêm, còn latency sao mà thay đổi được? latency nó phụ thuộc vào media và chất lượng cuả truyền dẫn, số lượng hop một packet đi qua, tạm xem là trong một mạng cục bộ chỉ có một broadcast domain, thì tất cả đều chung một segment, latency sẽ chi từ 1-2 ms và đây là con số sẽ không thay đổi trong một phiên, liệu có sự hiểu lầm gì ở đây không ạ?

Em xin lắng nghe bác kiến giải thêm ạ, chỉ thắc mắc là latency bao nhiêu ms thì sẽ không còn realtime nữa, và streaming vs livestream nó khác nhau như thế nào về mặt yêu cầu, chúng ta đang nói stream ở đây là stream nhạc và video, ví dụ như nghe nhạc và xem phim trực tuyến đi, reatime để làm gì và ảnh hưởng gì?, ta đâu có livestream bán hàng qua facebook, hay video call đâu? bác khai sáng cho em được không? em nói thật lòng, chỉ băn khoăn là bọn Tidal, Qobuz và các dịch vụ streaming có chứng nhận MQA có được xem là lĩnh vực đặc thù của audio bác đang nói không, nếu không thì chúng là gì ạ ? Cá nhân em chưa thấy hãng audio nào làm ra mấy DAC để thực hiện skype call, viber call, hay bất cứ dịch vụ reatime 2 chiều cả. Thực sự mong bác kiến giải thêm

Ngoài Linux và biến thể của Linux (nói chung là xuất phát từ linux core của linux foundation) ra mình còn sự lựa chọn nào nữa không bác?, theo em hiểu là Ms chưa từng làm các bản custom khác ngoài lĩnh vực PC và Server trên kiến trúc x86 (ngoài IA-64 đã gần tuyệt chủng) và sau này có hỗ trợ thêm cho ARM nhưng vẫn còn phải hoàn thiện nhiều nữa, cá nhân em chưa từng thấy con embeded devices nào chạy windows ạ, kể cả WinCE.

Mong bác chia xẻ kiến thức để mọi người hiểu thêm và bổ xung những cái còn thiếu.

Cám ơn bác

 

Data audio nó khác với các gói data khác, nó cần được đồng bộ với dữ liệu thời gian để DAC có thể tái tạo lại thành tính hiệu analog ít sai lệch nhất so với tính hiệu gốc (vì khi lấy mẫu để chuyển từ tín hiệu analog sang digital theo thời gian thực) nên cách truyền data audio cũng khác với truyền data bình thường. vd trong giao thức truyền usb có giao thức kiểm tra sửa lỗi nếu sai truyền lại nhưng các nhà sx phần mềm kg chọn giao thức này mà chọn truyền không sửa lỗi tập trung vào môi trường truyền tốt để hạn chế lỗi khi truyền như dùng cáp usb tốt, chống nhiễu tốt....khi truyền qua mạng cũng vậy cũng có những giao thức không kiểm tra sửa lỗi, tôi nhớ kg lầm thì RAAT mà Roon đang sử dụng.

 

Các bác tham khảo: https://viblo.asia/p/tim-hieu-giao-thuc-tcp-va-udp-jvEla11xlkw

 

Ôi trời tôi tưởng bác thế nào, ban đầu hơi hoang mang chưa hiểu ý bác, giờ thì không nghi ngờ gì nữa.

Thành thật khuyên bác nếu bác có background thật sự thì hãy phát biểu, không thì bác sẽ làm những người có hiểu biết nhất định họ hoang mang và ngỡ ngàng đấy.

Nếu bác có chuyên ngành điện tử- viễn thông (tôi cũng từng tốt nghiệp chuyên nghành này ở VN sau đó đi du học để học tiếp) và bác hiểu về điện tử số cũng như các hệ thống thu phát cả vô tuyến lẫn hữu tuyến, bác làm ơn chỉ cho tôi cái phương pháp truyền phát nào mà không cần đến tín hiệu đồng bộ? bác cắm con switch của bác vào mà monitor nó trên các scope và truyền data bất kỳ cả audio lần không phải audio, bác chỉ cho tôi đâu là xung đồng bộ của line và đâu là cái gọi là "xung đồng bộ của audio cho DAC làm việc", bác chụp cho tôi cái ảnh lên đây để minh họa cho cái xung đồng bộ cho audio của bác.

Bác còn không biết protocol nó là cái gì , quy tắc làm việc của nó thế nào, mà bác phát biểu ở rất nhiều topic trước (chiều giờ tôi đọc khá nhiều cái bác viết vì tò mò về bác, thật sự tôi thấy ngỡ ngàng và có chút ái ngại cho người khác khi nghe bác nói)

Bác nói xem, cái dữ liệu truyền trên mạng của bác nó là dư liệu gì, cấu trúc nó ra sao ? bác có hiểu cái chiều ngược lại của điều chế PCM ( điều chế xung - mã) trên các thiết bị giải mã nó là như thế nào không? nói đơn giản để bác hiểu là người ta vẽ lại cái đường cong gần giống tín hiệu analog trước khi lây mẫu dựa trên các bit thông tin ghi tại các giá trị được lấy mẫu tín hiệu. xung đồng bộ nào ở đây cha nội? thông tin định dạng của file fỏmat âm thanh, sampling rate..etc nó nằm ở header của file, DAC ban đầu extract cái này từ header file, sau đó mới process bước kế tiếp, Với trường hợp upconvert on the fly thì DAC sẽ dũng internal clock riêng của nó để thực hiện việc tái lấy mẫu lần nữa trên cở sở nội suy, khi tín hiệu từ line đến đến etherint thì nó đã strip out các packet và parse ra các bit data rôi, xung nào từ line lọt vào được đến đây tại cái mạch DA bác đang nói đến? nếu nói rằng đó là nhiễu lan sang gây ảnh hưởng đến audio spectrum bên khối analog thì còn có vẻ biết tí chút.

Tôi đọc rất nhiều post cuả bác ở trên đây, thật sự ai ngại với kiến thức của bác, một sự chắp vá lợm lặt từ nhiều nơi, không có khả năng tự kiểm chứng và cũng không có một lý luận gì từ kiến thức nền tảng cả, bác phát biểu nhiều cái mà tôi đọc thấy rất ngỡ ngàng pha lẫn sửng sốt, vậy mà sao có nhiều người tin và cổ xúy vậy nhỉ ???

Anyway, RAAT là gì và nó hoạt động ở layer mấy hả bác? cái underlying protocol cuả nó là gì bác biết không?

Bác làm ơn biết thì phát biểu, đừng đầu độc người khác với những cái suy nghĩ nguy hiểm như thế, nó cho cho thấy một con số 0 về mặt kiến thức. Bậy bạ hết sức.

Quay trở câu hỏi rất rất cơ bản là các thiết bị chuyển mach nó dùng bộ tạo mã nào để tạo xung trên tín hiệu truyền, tốc độ 10, 100, 1000, 10G nó sử dụng các line coding nào ? với cáp quang thì sao, nó dùng điều chế quang kiểu gì ? bác trả lời đúng thì ta nói chuyện tiếp nhé, cái này rất cơ bản và thuần lớp physical bên dưới, thực sự có học hành bài bản thì sẽ trả lời được cái này.

Về mấy cái TCP - UDP protocol trên link bác gởi thì là mấy cái bài giới thiệu vỡ lòng, mình làm Developer cho Nortel Network ở Mỹ gần 10 năm trước khi nó phá sản, chuyên implement các giao thức lớp 2, và một số cái lớp 3 này theo IEEE và RFCs cho các dòng swicth module dùng trên các hệ thống BladeCenter-T/H của IBM, mình không hề lạ về máy cái vỡ lòng các bác đây đang tìm hiểu. header của từng protocol mình thuộc từng bit và ý nghĩa của nó nhé, mình hoàn toàn có thể viết sách về nó nếu có thời gian và hứng thú bác ạ. Mình nghiền ngẫm và thuộc các RFCs để tuân thủ nó khi implement còn nhiều hơn cả bác ăn cơm hàng ngày, bác không cần đi dạy ngược lại mình.

Bác còn không biết được các streaming service hoạt hoạt động như thế nào khi mình hỏi, khi nào thì dùng UDP, khi nào thì dùng TCP, đừng có gói gọn máy cái hiểu biết lượm lặt của mình trong mấy cái "audio" của bác nhé. Thế giới công nghệ điện tử - viễn thông nó bao la hơn nhiêu khi xu hướng hội tụ đa dịch vụ trên nền tảng IP là điều tất yếu và nó đã diễn ra từ 10 năm trước rồi. cái "audio" của bác nó chỉ bé như cái móng tay trong một bức tranh công nghệ mà thế giới đang vận hành hàng ngày.

Nói thật là mình cũng đã từng là dân "điện tử chợ" từ những năm 90 khi mới ra trường và chưa kiếm được việc làm, chuyên làm các board chuyển đổi hệ NTSC sang PAL của TV nhật nội địa, trước đó là các bộ giải mã tiếng để thu các kênh của Nga phăt từ các Đại sứ quán ở VN, gia công các bộ equalizer dùng cho các dàn karaoke bán ở chợ từ những năm 90, lúc đấy còn chưa biết bác đang ở đâu và đã học xong mẫu giáo chưa.

Trong xứ mù thì thằng chột làm vua, nhưng đầu độc và làm người khác ngộ nhận về những cái cơ bản thì có tội với kiến thức của nhân loại, đi ngược lại sự văn minh của loài người đấy.

Miễn tranh luận ở đây vì mình hiểu cái background của bác rồi.

 

Bác hỏi và nói nhiều quá nếu bác muốn biết thì tự tìm hiểu nhiều thêm nhé tôi không muốn tranh luận với bác.

 

À, thì ra vậy, bác giữ lại câu trên cho chính bác, cẩn thận hơn khi đi chém chỗ khác nhé

 

tôi kg rãnh mà đi chém gió như bác thật ra qua các bài viết của bác tôi biết bác là dân cntt chẳng am hiểu gì về audio cả. tôi cũng chẳng phải là dân thợ như bác chỉ là người chơi audio và có thể tự làm ra sản phẩm để phục vụ cho nhu cầu của chính mình đúng nghĩa "Do it your self". còn những gì tôi nói ai thích thì nghe còn kg thì thôi kg ép buộc ai phải làm theo cả.

 

à mà còn nữa bác đừng mang cái sự học của mình ra mà khoe khoan ở đây. ở đây chắc cũng có nhiều người được học hành bài bản thậm chí hơn cả bác. tặng bác câu này "Cao nhân tất hữu cao nhân trị".