toi511
Well-Known Member
Để cuối tuần rảnh em nghe thử
Raspberry Pi + Rune Audio ::: Một trải nghiệm nghe nhạc mới
- Bắt đầu smallgent
- Ngày bắt đầu
linh0983
Well-Known Member
Theo tôi thẻ extreme pro 1T duyệt nhanh hơn nữa bác ạ . Sáng nay on pi2 thư viện nhạc 1T hdd có ngay play ngon lành ko như lúc trước với rAudio ạ .Với Pi2 piCorePlayer duyệt nhanh hơn rAudio bác Hùng ạ .
Khi nào rảnh ghé tôi ui . . .
rndce
Well-Known Member
Bác @quatmo, có cách nào cài Youtube Cast lên Moode 8.3.9 hay Moode 9. koah?Bản Lyrion RT 1.4 - cho Pi 4 và Pi 5. Hầu hết tính năng chính đã hoàn chỉnh.
Lyrion-RT-1.4f1.zip
drive.google.com
Lúc play Youtube Cast các bác kết nối Youtube trên phone với Pi, Google hỏi đăng nhập các bác có thể bấm "Cancel" nó vẫn kết nối play được.
Giải pháp play Youtube Cast này chơi lâu dài không lo lắng gì, vì Youtube link code là của Google cung cấp chính thức.
-------------
Nâng cấp mới: Parametric Equalizer (đặc biệt hữu ích cho bác chuyên đeo tai nghe headphone).
--------------
https://autoeq.app web mẫu thông số Parametric Equalizer dành cho tai nghe (nhập vào nhãn hiệu).
-------------
Các bác mê nhạc ngoại có thể khám phá sẵn vài ngàn Radio, mình sưu tầm để sẵn, các bác bấm vào mục Playlist. Trong đó có nhiều đài nghe chất lượng không tồi đâu.
Điển hình đài Radio FLAC chất lượng Bitrate rất cao. Có cả Hi-Res
--------------
Nếu điều khiển Lyrion LT Pi bằng máy tính thì mở web http://lyriano.local/
Điều khiển Lyrion LT Pi từ phone mở web IP máy.
--------
linh0983
Well-Known Member
quatmo
Well-Known Member
Cách đơn giản nhất là bác vào SSH Moode sửa file này
/home/xinitrc.default
Config ban đầu:
chromium-browser --app="http://localhost/" \
--window-size="$SCREEN_RES" \
--window-position="0,0" \
--enable-features="OverlayScrollbar" \
--no-first-run \
--disable-infobars \
--disable-session-crashed-bubble \
--kiosk
thành như sau:
chromium-browser \
--window-size="$SCREEN_RES" \
--window-position="0,0" \
--enable-features="OverlayScrollbar" \
--no-first-run \
--disable-infobars \
--disable-session-crashed-bubble \
Sau đó trên màn hình HDMI sẽ xuất hiện giao diện trình duyệt chrome, bác vào google extension cài plugin Youtube TV On PC rồi reboot.
Bác sẽ thấy đúng giao diện Youtube TV, có menu bên trái - bấm icon Setting, bấm Link Code. Kết nối phone, kết nối thành công play Ok từ phone sang.
Rồi trả về Config ban đầu lưu lại, vì đã kết nối phone xong.
Câu hỏi này cực kỳ hay và đáng giá cho dân audio hi-end:
[ VSound + netmap ] [ HQPlayer NAA ] [ Roon RAAT ]
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Ethernet Frame│◄──────▶│ UDP + FEC │◄──────▶│ TCP │
└───────────────┘ └───────────────┘ └───────────────┘
(Layer 2) (Layer 4) (Layer 4)
Ultra low latency ⚖ Balance High stability
Tóm tắt khác biệt chính:
| Tiêu chí | VSound (netmap) | Roon / HQPlayer |
|---|---|---|
| Giao thức truyền | Raw PCM qua netmap (Ethernet-level, không TCP/IP) | TCP/IP hoặc UDP (RAAT, NAA, HTTP) |
| Tầng mạng | Tầng Ethernet (L2, cực thấp) | Tầng Application/Transport (L5–L7) |
| Tự sửa lỗi (retransmit) |  Không có |  Có (Roon RAAT = TCP, HQPlayer NAA = UDP + FEC) |
| Chống jitter tự nhiên | Tối ưu cực thấp jitter | Phụ thuộc phần mềm & OS |
| Bit-perfect | Bit-perfect, raw stream | Bit-perfect nếu không DSP |
| Độ trễ | Rất thấp (micro giây – ms) | Cao hơn (vài ms – chục ms) |
| Phù hợp cho gì? | Realtime playback, reclock I²S DAC | Control đa thiết bị, dễ dùng UI |
| Khả năng chịu lỗi | Kém hơn, dễ nghe thấy lỗi nếu có | Chịu lỗi tốt, không gây nổ tiếng |
Giải thích chi tiết từng nền tảng:
1. VSound + Netmap (Symphonic-MPD)
- Truyền raw PCM trực tiếp qua Ethernet frame (Layer 2)
- Không dùng TCP/IP, UDP, không có header phức tạp
- Truyền kiểu “zero-copy”, độ trễ và jitter rất thấp
- Gần như tương đương giao tiếp nội bộ, phù hợp reclock I²S DAC
- Nhưng: Không có cơ chế sửa lỗi → nếu nhiễu mạng, bạn nghe ra tiếng “bụp” hoặc mất âm ngay
2. Roon RAAT (Roon Advanced Audio Transport)
- Giao thức độc quyền của Roon
- Dựa trên TCP, có buffer lớn và tự sửa lỗi khi mất gói
- RAAT đảm bảo:
- Bit-perfect
- Gửi lệnh điều khiển (play, pause, sync nhiều phòng)
- Gửi metadata (bìa album, tín hiệu MQA, v.v.)
- RAAT có độ trễ khoảng 20–200ms, bù lại rất ổn định
3. HQPlayer + NAA (Network Audio Adapter)
- Giao thức riêng dựa trên UDP + FEC (Forward Error Correction)
- Ưu tiên thời gian thực hơn là độ ổn định tuyệt đối
- Được thiết kế để:
- Gửi PCM hoặc DSD lên đến 32bit/768kHz hoặc DSD1024
- Phát bit-perfect đến endpoint
- Có thể truyền qua mạng tốt, nhưng buffer cũng tầm 10–50ms
Hình ảnh dễ hiểu:
Mức mạng[ VSound + netmap ] [ HQPlayer NAA ] [ Roon RAAT ]
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Ethernet Frame│◄──────▶│ UDP + FEC │◄──────▶│ TCP │
└───────────────┘ └───────────────┘ └───────────────┘
(Layer 2) (Layer 4) (Layer 4)
Ultra low latency ⚖ Balance High stability Khi nào chọn VSound, HQPlayer hay Roon?
| Nhu cầu | Nên chọn |
|---|---|
| Tối ưu jitter thấp nhất, chơi reclock I²S DAC | VSound + netmap |
| Upsample cực mạnh, chơi DSD1024 | HQPlayer + NAA |
| Dễ dùng, giao diện đẹp, đa phòng | Roon RAAT |
| Ưu tiên âm thanh hơn tính năng | VSound / HQPlayer |
| Ưu tiên UI, metadata, DSP | Roon |
Kết luận
- VSound + netmap là lựa chọn "hardcore" audio, gần như truyền PCM từ RAM thẳng ra I²S – tối ưu cho DAC rời + reclock
- Roon RAAT và HQPlayer NAA là hệ thống “có độ an toàn”, tự sửa lỗi, dễ dùng nhưng bù lại độ trễ cao hơn
- Dùng VSound yêu cầu:
- Hệ thống mạng sạch
- NIC tốt, switch ổn định
- Không có backup/torrent cùng lúc
quatmo
Well-Known Member
Bác play AoE 2 máy bị jitter hay play Roon 2 máy bị jitter ?
Như bài trên bác ghi AoE "Tối ưu cực thấp jitter" nên mình không hiểu bác đang nói về cái nào.
Bác play I2S hay USB?
AoE tất nhiên là play 2 máy gồm PC hoặc Pi sang 1 Pi render ra I2S DAC thông qua router dây LAN. Mục đích tránh việc tín hiệu - dữ liệu - CPU xử lý nhiều thứ cùng lúc gây jitter sang render. AoE chạy Real-time kernel.
Pi 5 + Real-time kernel đã giảm phần lớn độ trễ như các bài test của mình đo bằng: phần mềm Cyclictest khi play file FLAC.
PC Intel J1900 cài OS Euphony Real-time kernel play 1 máy độ trễ 90us ~ up.
Pi 4 Real-time kernel play 1 máy 45 ~ 55 us
Pi 5 Real-time kernel play 1 máy: 8 ~ 20 us
Pi 5 Real-time kernel play 2 máy Vsound: 5 ~ 15 us
Độ trễ càng thấp gián tiếp giảm jitter. Vì CPU không bị stress.
Khi tín hiệu raw bị chạy qua nhiều link kiện, ic hoặc bị chuyển đổi thành các dạng khác (vd như i2s -> usb -> i2s ) thì bị tăng jitter đó bác.
Khi chơi 2 máy thì tín hiệu raw phải chạy qua ít nhất là chip ethernet (tín hiệu raw khi qua ethernet ko biết có bị đổi định dạng như khi qua chip usb ko) của 2 máy, dây LAN, SW, 1 mớ linh kiện tụ trở... Thay vì chạy thẳng ra dac nên chắc chắn jitter tăng nhiều.
Việc giải mã pcm rất nhẹ nên nếu chơi 2 máy để giảm tải cho cpu mình thấy cũng ko được lợi nhiều. Trừ phi chơi upsampling thì buộc phải dùng 2 máy rồi.
Khi chơi 2 máy thì tín hiệu raw phải chạy qua ít nhất là chip ethernet (tín hiệu raw khi qua ethernet ko biết có bị đổi định dạng như khi qua chip usb ko) của 2 máy, dây LAN, SW, 1 mớ linh kiện tụ trở... Thay vì chạy thẳng ra dac nên chắc chắn jitter tăng nhiều.
Việc giải mã pcm rất nhẹ nên nếu chơi 2 máy để giảm tải cho cpu mình thấy cũng ko được lợi nhiều. Trừ phi chơi upsampling thì buộc phải dùng 2 máy rồi.
Chỉnh sửa lần cuối:
quatmo
Well-Known Member
Bác nghe thử Vsound chưa?
Bác play vsound rồi xem service trong linux của nó sẽ thấy truyền qua địa chỉ MAC từng group data qua Netmap (bác đọc google tài liệu Netmap) nó là định dạng đặc biệt dùng trong truyền dẫn tốc độc cao (có thể nói là tốc độ tối ưu nhất cho thời gian thực), máy FE đẩy ra Vsound, FE nó nhận máy BE qua địa chỉ MAC. (Hình như mình có để link tài liệu Netmap và Real-time bên VNAV)
Không liên quan gì USB hay bị chuyển đổi cả, Vsound - Raw - Netmap chỉ đi qua dây LAN dùng MAC (không wifi), ví dụ Tidal/Qobuz truyền cái file đến Music Sever DAC nó sẽ đi qua TCP/IP, cơ mà nghe nhạc nó vẫn hay dù từ Server chứa nhạc cách 1 vòng trái đất, vậy nên loại trừ jitter do truyền dẫn (mấy năm trước từng test bằng cách coi link stream Tidal - download file Flac từ Tidal về nghe so với nghe online => không khác nhau, chắc tai trâu).
Còn AoE không truyền nguyên cái file đi, mà truyền từng group Raw data, nhằm loại trừ jitter do CPU xử lý gây nên.
Nói dễ hiểu trong chụp ảnh chuyên nghiệp, máy ảnh lưu ảnh Raw (1 file ảnh khoảng vài chục MB - hơn 100 MB) là lưu giữ bit data nguyên bản thông số ánh sáng, nhờ đó bức ảnh Raw chỉnh sửa dễ dàng hơn ảnh lưu dạng file nén JPG. Này cũng tương tự vậy data bit nguyên bản đẩy đi nhờ tốc độ cao nhờ "cao tốc Netmap" và không bị nén hay chỉnh sửa - không bị sai lệch bit - không cần fix bởi reclock router.
Cơ chế Netmap truyền gần như ngay tức thời từng gói Raw (không cần router reclock - fix data bit..) qua dây LAN đến đầu máy nhận máy nhận là Pi 4 nhận data tổng họp lại đẩy ra I2S DAC cũng không liên quan gì USB cả. Hiện nay chưa thấy bản AoE nào chạy USB DAC.
Nhóm symphonic-mpd.com Nhật đã có nhiều năm tối ưu và nâng cấp, ban đầu là SMPD cho Pi 2 mà trước kia anh em hay dùng, sau symphonic-mpd họ nâng thành AoE realtime, bác vào diễn đàn họ để xem.
Còn tại sao OS này hay hơn OS kia. Nói đơn giản - cài Roon Server lên PC Windows thường, nghe không bao giờ qua được OS Euphony, đơn giản là Euphony cách ly CPU - độ trễ thấp hơn Window rất nhiều, không gây ra stress cpu (xung nhịp/s). Mấy năm qua anh em hay chơi bản Windows LTSC (thường là những bản IOT) cho phép can thiệp cách ly CPU/ giảm tải process, để cài Roon. Lý do giảm tải CPU là vậy, giảm độ trễ tín hiệu audio.
Nói thêm:
Kiến thức mình góp nhặt AoE qua đo đạc và xem tài liệu, không dùng ChatGPT, vì nhều lúc nó tào lao ba phải lắm, copy bài này bỏ vào hỏi nó, nó bảo phân tích đúng... mà nó chả đưa ra tài liệu dẫn chứng nào cả.
Tuy nhiên bửa giờ build ít nhất 5 OS Linux RealTime cho PC, Pi để test toàn nhờ ChatGPT hướng dẫn.
Chỉnh sửa lần cuối:
Cái vụ usb là mình lấy ví dụ minh họa cho việc tín hiệu bị convert từ i2s sang usb nó bị tăng jitter thôi bác. Nhưng ở đây mình hơi nhầm nhọt là pcm từ FE sang BE chưa có clock nên ko bị jitter. Pcm sau khi BE render ra i2s mới có clock thì khái niệm jitter mới xuất hiện.
Nhưng PCM là tín hiệu đã được decode bởi FE thường ko được sửa lỗi khi đến BE nên trên đường đi của nó nếu qua nhiều vật trung gian sẽ dễ bị lỗi gây giảm chất lượng tín hiệu.
Còn tidal, quobuz thì mình nghĩ nó giống NAS tức là copy file nhạc gốc vào pi nên tự sửa lỗi và toàn vẹn dù đi nửa vòng trái đất.
Nhưng PCM là tín hiệu đã được decode bởi FE thường ko được sửa lỗi khi đến BE nên trên đường đi của nó nếu qua nhiều vật trung gian sẽ dễ bị lỗi gây giảm chất lượng tín hiệu.
Còn tidal, quobuz thì mình nghĩ nó giống NAS tức là copy file nhạc gốc vào pi nên tự sửa lỗi và toàn vẹn dù đi nửa vòng trái đất.
Bài mới nhất
-
Robot tự hành tại các kho hàng Amazon sắp nhiều bằng con người- Mới nhất: NhatTrungNguyen
-
-
Qantas Airways bị tấn công mạng, nguy cơ rò rỉ dữ liệu nhạy cảm của 6 triệu khách hàng
- Mới nhất: NhatTrungNguyen