Raspberry Pi + Rune Audio ::: Một trải nghiệm nghe nhạc mới

quatmo

Well-Known Member
Có bác PM hỏi mình, xài cái nào ngon, nhiều kết nối. Mình trả lời chung ở đây

Muốn ổn mà nhiều kết nối nhất hãy dùng hệ sau:
Daphile (bung IMG ra USB cắm vào PC)
PiCorePlayer (bung thẻ nhớ cắm vào Pi)


- Youtube play ngon, luôn ổn định

- Tidal (add accout) xài trực tiếp không cần truyền từ phone sang

- Qobuz (add accout) xài trực tiếp không cần truyền từ phone sang

- Spotify (add accout) xài trực tiếp không cần truyền từ phone sang

- Deezer (add accout) xài trực tiếp không cần truyền từ phone sang

- NAS, USB đều ngon

- Fix lỗi, update thường xuyên, cộng đồng phát triển plugin lớn.

- Có app remote control trên phone lẫn PC

Âm thanh không tệ đâu

PiCorePlayer hơi phức tạp về setting đối với người sử dụng lần đầu, để thuận tiện cho các bác vọc, mình tạo bản IMG PiCorePlayer 7.0, đã cấu hình sẵn.

1. Các bác dowload về bung ra thẻ cắm Pi

2. Dùng Advanced IP Scanner để tìm IP của Pi

3. Vào IP Pi/ để vào PiCorePlayer setting: thiết lập NAS, USB, chọn DAC... và LCD (phần LCD này bác nào không dùng thì bấm remove).

4. Vào IP Pi:9000/ để vào Player LMS Server setting, thiếp lập TK Youtube, Spotify, Dezzer, Qobuz... Với Tidal cần phải đăng ký TK mysqueezebox.com sau đó dùng trình duyệt VPN (Opera) để đăng nhập mysqueezebox.com active cái App Tidal lên

5. Mình đã cài Plugin skin Material, các bác vào IP:9000/ sẽ thấy rất đẹp, nhẹ, support mobile

Download ở đây:
https://drive.google.com/file/d/1zqd00GN_PEtqs4Hss7bB5TkjWgVOYqGD/view?usp=sharing

Cập nhật:
Bác nào bung IMG ra mà không vào LMS Player (IP:9000/) được thì hãy vào PiCorePlayer IP/ bấm hết các cập nhật (update): Main piCorePlayer update, pCP updates...

1591656648589.png


(Copy cái hình LMS material Skin của ai đó vào cho nó sinh động)
 
Chỉnh sửa lần cuối:

VugiaA9

Active Member

linh0983

Well-Known Member
Hình như cái Arch Linux AOE này có thể cài trên PC X86, X64 bác nhỉ :D
Để em thử lôi con lattepanda ra cài thử. Khổ nhà nghèo có 1 con Pi4, 3 con Pi2 mà ko có Pi3, cài Pi2 sợ yếu :D
Mình mail họ cái file này dùng cho PC làm FE a : x86_64-upnpgw-aoe-b7 về mình send a . o_O
 

linh0983

Well-Known Member
Mình thích dùng dây ko thích wifi . ;)
Các bác ko thích dây thì thêm wifi cho nó a . ( mặc định smpd họ cắt hết a ) . :rolleyes:
Nhập như vầy :

cd /etc/netctl/examples
cp wireless-wpa-static ../wlan0-static
cd ../


nano wlan0-static
D6.jpg


D7.jpg


netctl enable wlan0-static
netctl start wlan0-static
reboot


Dùng PuTTY hoặc WinSCP vào lòng nó a . :D
 

Thanhvo31

Well-Known Member
@linh0983
Kiểm tra kỹ rồi mà vẫn không lên được bác ạ:(

BACK END
config.txt >>> dtoverlay = allo-digione
cmdline.txt >>> ip = 192.168.11.113:255.255.255.0:192.168.11.1
ping 192.168.11.113
Pinging 192.168.11.113 with 32 bytes of data: Reply from 192.168.11.113: bytes=32 time=19ms TTL=64 Reply from 192.168.11.113: bytes=32 time=6ms TTL=64 Reply from 192.168.11.113: bytes=32 time=8ms TTL=64 Reply from 192.168.11.113: bytes=32 time=8ms TTL=64 Ping statistics for 192.168.11.113: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 6ms, Maximum = 19ms, Average = 10ms
Nghĩa là BACK END ngon!

FRONT END
vsound.service - Audio over Ether Virtual Sound Card
Loaded: loaded (/usr/lib/systemd/system/vsound.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-01-14 20:10:28 JST; 41min ago
Main PID: 221 (aoe)
Tasks: 1 (limit: 2150)
CGroup: /system.slice/vsound.service
└─221 /usr/bin/aoe -i eth0 -d DC:A6:32:0E:39:10
Jan 14 20:10:28 archlinux64 systemd[1]: Starting Audio over Ether Virtual Sound Card...
Jan 14 20:10:28 archlinux64 systemd[1]: Started Audio over Ether Virtual Sound Card.
Jan 14 20:10:28 archlinux64 aoe[221]: 628.936806 main [ 928] 0| HWaddr dc:a6:32:10:c2:4e
Jan 14 20:45:00 archlinux64 aoe[221]: 700.282119 main [1005] 0| SND_PCM_STATE:pREPARED(2) S32_LE 44100 2, send *Neighbor Discovery*
Jan 14 20:45:00 archlinux64 aoe[221]: 700.382179 main [1005] 0| SND_PCM_STATE:pREPARED(2) S32_LE 44100 2, send *Neighbor Discovery*
Jan 14 20:45:00 archlinux64 aoe[221]: 700.419077 unbox [ 597] 49204| recv *SYN* CLOSED->CONNECTED chunk_bytes:1176, send *ACK*
*************************************---------
Bác xem giúp log này có OK không?


ACtC-3co6T3fhf3qmmeA0tvLJyyoPTasKRci7677VJP8DYIuj9NNFkSg0o1eq-260yX2R4fBs9iBcLZjSbURUEKTF7fdM3c9VWiXONuPUXOWDLpDu0m_XdCP-BLtBvmvU9-Q_BSmMW1JhBe3q6LNzuhuHVrs1g=w1329-h1419-no
 
Chỉnh sửa lần cuối:

Thanhvo31

Well-Known Member
Bác cấu hình cho chú dac bên phần BE chưa a ? :eek:
Có dtoverlay = allo-digione

[root@archlinux64 ~]# lsaoe
TARGET [dc:a6:32:e:39:10]
AoE STATUS : CONNECTED
AoE SESSION: 50336
PCM STATE : OPEN(0)
PCM PARAM : S32_LE 44100 2 chunk_bytes:1176 period_us:3333
AoE STATS : avg 1620(us), min 1496(us), max 1616(us) (count:511 timeout:0 recover:0)


++++++++++

[root@archlinux64 ~]# aoestat
period : 3333(us)
poll timeout : 196(ms) (mit 4)
receive packets : 9099 (AoE 511, Others 8588)
poll total : 14
poll/chunk x100 : 2
dreq/chunk x1000: 15
trip/chunk : 25(us)
act /chunk : 25623(ns)
 

linh0983

Well-Known Member
Có dtoverlay = allo-digione

[root@archlinux64 ~]# lsaoe
TARGET [dc:a6:32:e:39:10]
AoE STATUS : CONNECTED
AoE SESSION: 50336
PCM STATE : OPEN(0)
PCM PARAM : S32_LE 44100 2 chunk_bytes:1176 period_us:3333
AoE STATS : avg 1620(us), min 1496(us), max 1616(us) (count:511 timeout:0 recover:0)


++++++++++

[root@archlinux64 ~]# aoestat
period : 3333(us)
poll timeout : 196(ms) (mit 4)
receive packets : 9099 (AoE 511, Others 8588)
poll total : 14
poll/chunk x100 : 2
dreq/chunk x1000: 15
trip/chunk : 25(us)
act /chunk : 25623(ns)
Như vầy là kết nối rồi bác a . Mình và bác 2 code i2s khác nhau . Cái này mình mò trộm ko biết có giúp ích gì ko ? S32 trong /etc/asound.conf bác đổi đổi thành S24 trước khi đổi bác phát nhạc 48Khz xem nó có kêu ko kế đó là 44,1 Khz . Nếu mình có chú Digione dễ mò mẫm hơn a . :rolleyes:
 

linh0983

Well-Known Member
Mình hiểu chậm, symphonic MPD là giao thức truyền tải tín hiệu mới sử dụng nhiều pi mục đích giảm thiểu nhiễu phải không các bác? Thực tế dùng thì bác cảm nhận ntn so với những cách khác ah ?
Bác dev Paparius trả lời đây a . ( google dịch) . :oops:
Tách biệt là một cấu hình phân phối tải được tạo ra và triển khai trong sê-ri v0.4. Nó là một phương pháp chia thành hai cấu hình, front endback end, và chuyển dữ liệu PCM được giải mã bởi RPi phía trước sang RPi phía sau thông qua mạng LAN để phát lại. Quá trình ở mặt sau chịu trách nhiệm cho đầu ra I2S có thể được giảm đáng kể, hoạt động lõi đơn có thể thực hiện được và có thể tránh được chi phí phát sinh từ SMP. Tại thời điểm sê-ri v0.4, hình ảnh SD chuyên dụng mặt sau do @ donuts-shop73 phát triển có mức tải CPU cực thấp, có hiệu suất thời gian thực vượt trội hơn so với nhân RT và có chất lượng âm thanh ở mức cao nhất. Tôi nghe nói rằng Diretta nhằm mục đích tối ưu hóa giao tiếp bằng cách sử dụng giao thức riêng và giao tiếp thông suốt bằng cách sử dụng điều khiển bộ đệm. Việc tách dòng v1.0 mà tôi hiện đang làm cũng nhằm mục đích tương tự, nhưng nó đi xa hơn về mặt giảm tải giao tiếp, làm mượt, giảm tải phát lại và giảm thiểu độ trễ. Trở nên. Trình điều khiển được triển khai trong sê-ri v1.0 giảm chu kỳ CPU cần để xử lý khoảng 95% so với phát lại bằng trình điều khiển ALSA tiêu chuẩn của Linux. Ngoài ra, chúng tôi đã thiết kế cẩn thận để không xảy ra các cuộc gọi hệ thống, chuyển đổi ngữ cảnh và bộ nhớ cache CPU gây ra độ trễ lớn (dao động trong thời gian xử lý). Chúng tôi dự định chuẩn bị một trình điều khiển chuyên dụng để liên lạc trong một cấu hình riêng biệt. Tính năng lớn nhất là nó bỏ qua ngăn xếp mạng của nhân Linux, loại bỏ quyền truy cập bộ nhớ gần như dư thừa như sao chép gói từ FIFO của NIC sang không gian nhân và sao chép gói từ không gian nhân sang không gian người dùng, giao hưởng- Nó sẽ hoạt động liền mạch với công cụ phát lại mpd (trình điều khiển rtalsa / trình điều khiển xsink).
 

VugiaA9

Active Member
Bác dev Paparius trả lời đây a . ( google dịch) . :oops:
Tách biệt là một cấu hình phân phối tải được tạo ra và triển khai trong sê-ri v0.4. Nó là một phương pháp chia thành hai cấu hình, front endback end, và chuyển dữ liệu PCM được giải mã bởi RPi phía trước sang RPi phía sau thông qua mạng LAN để phát lại. Quá trình ở mặt sau chịu trách nhiệm cho đầu ra I2S có thể được giảm đáng kể, hoạt động lõi đơn có thể thực hiện được và có thể tránh được chi phí phát sinh từ SMP. Tại thời điểm sê-ri v0.4, hình ảnh SD chuyên dụng mặt sau do @ donuts-shop73 phát triển có mức tải CPU cực thấp, có hiệu suất thời gian thực vượt trội hơn so với nhân RT và có chất lượng âm thanh ở mức cao nhất. Tôi nghe nói rằng Diretta nhằm mục đích tối ưu hóa giao tiếp bằng cách sử dụng giao thức riêng và giao tiếp thông suốt bằng cách sử dụng điều khiển bộ đệm. Việc tách dòng v1.0 mà tôi hiện đang làm cũng nhằm mục đích tương tự, nhưng nó đi xa hơn về mặt giảm tải giao tiếp, làm mượt, giảm tải phát lại và giảm thiểu độ trễ. Trở nên. Trình điều khiển được triển khai trong sê-ri v1.0 giảm chu kỳ CPU cần để xử lý khoảng 95% so với phát lại bằng trình điều khiển ALSA tiêu chuẩn của Linux. Ngoài ra, chúng tôi đã thiết kế cẩn thận để không xảy ra các cuộc gọi hệ thống, chuyển đổi ngữ cảnh và bộ nhớ cache CPU gây ra độ trễ lớn (dao động trong thời gian xử lý). Chúng tôi dự định chuẩn bị một trình điều khiển chuyên dụng để liên lạc trong một cấu hình riêng biệt. Tính năng lớn nhất là nó bỏ qua ngăn xếp mạng của nhân Linux, loại bỏ quyền truy cập bộ nhớ gần như dư thừa như sao chép gói từ FIFO của NIC sang không gian nhân và sao chép gói từ không gian nhân sang không gian người dùng, giao hưởng- Nó sẽ hoạt động liền mạch với công cụ phát lại mpd (trình điều khiển rtalsa / trình điều khiển xsink).
Em cũng tạm hiểu là kiểu con front-end nó "bung nén" dữ liệu ra sẵn, đẩy sang back-end chỉ việc chơi nhạc. Pi xuất âm (back-end) gần như ko phải tải gì mà chỉ chơi mỗi trình phát nhạc kiểu media player nên chạy cực nhẹ và hệ điều hành cũng được viết để chạy đơn nhân, xung thấp để giảm tối đa nhiễu.
Haizzz. Kiểu này lại tốn dây mạng rồi :D
Cơ mà em thấy đây cũng là một cách làm thông minh. Nếu hệ điều hành SMPD phát triển thêm để tối ưu cho chơi DSD nữa thì rất hứa hẹn. Lúc này dùng máy tính mạnh làm front-end nữa là đẹp :D
Cơ mà em vẫn đang ko hiểu lắm là sao lại dùng P3 làm front-end còn Pi4 làm back-end. Về lý thuyết thì back-end nên ưu tiên máy tính nhẹ làm back-end để giảm nhiễu. Có thể do Pi4 có ưu thế về ram hơn, load nhạc vào ram và làm buffer tốt hơn chăng???
 
Chỉnh sửa lần cuối:
Bên trên