Archphile - μια audiophile διανομή για Raspberry Pi, Udoo, Cubox-i και Odroid C1+/C2

Παίζοντας εδώ και μέρες, έχω παρατηρήσει κάπως περίεργη συμπεριφορά με USB dac.

Υπάρχουν διακοπές (στην περίπτωσή μου πάρα πολυ συχνές) στην αναπαραγωγή ακόμα και σε 24/192, ενώ παράλληλα δεν έχω μπορέσει να πάρω κάποιο log που να αναφέρει κάποιο πρόβλημα.

Εκτός απο την προσωπική μου εμπειρία, έχω μέχρι στιγμής feedback από έναν χρήστη με αντίστοιχό πρόβλημα.

Όσοι λοιπόν δουλεύετε το RPI με USB dac και πιο συγκεκριμένα με το τελευταίο 3 B+, κάντε έναν κόπο να δοκιμάσετε από 16/44.1 μέχρι και το πιο "ακραίο" αρχείο που έχετε και γράψτε μετά αν θέλετε 2 λόγια.
 
Για να γίνω πιο σαφής ως προς το πρόβλημα που έχω εντοπίσει εγώ, οι διακοπές που έχω οφείλονται στο συνδυασμό ethernet/usb dac.

Αν φορτώσω πχ DXD αρχεία σε ένα στικάκι, η αναπαραγωγή είναι απρόσκοπτη. Αυτή η αλληλεπίδραση ethernet/usb, μου θυμίζει τα πρώτα προβλήματα που είχα αντιμετωπίσει το 2014 και που οφείλονταν στο shared bus.

Κάτι μου λέει ότι το πρόβλημα θα εντοπίζεται στο νέο ethernet chip και στους drivers κλπ.

Για να δούμε..
 
Για να γίνω πιο σαφής ως προς το πρόβλημα που έχω εντοπίσει εγώ, οι διακοπές που έχω οφείλονται στο συνδυασμό ethernet/usb dac.

Αν φορτώσω πχ DXD αρχεία σε ένα στικάκι, η αναπαραγωγή είναι απρόσκοπτη. Αυτή η αλληλεπίδραση ethernet/usb, μου θυμίζει τα πρώτα προβλήματα που είχα αντιμετωπίσει το 2014 και που οφείλονταν στο shared bus.

Κάτι μου λέει ότι το πρόβλημα θα εντοπίζεται στο νέο ethernet chip και στους drivers κλπ.

Για να δούμε..
Μιχάλη αυτό είναι θέμα kernel για να λυθεί;
Αν είναι έτσι δλδ;
 
Ας μην προτρέχουμε!

Μπορεί να είναι κάποιο bug που σχετίζεται με το Archphile/ArchlinuxARM κλπ.

Πάντως αν έχει σχέση με όσα λέω παραπάνω και είναι όντως τέτοιο θέμα, θα λυθεί με επόμενo kernel. Ήδη πέρασα τον επόμενο που έχει βγει αλλά δυστυχώς δεν άλλαξε κάτι.

Αυτο που είναι βασικό είναι:

1. Να δουμε ποσοι από εμάς έχουμε αυτό το πρόβλημα
2. Να διαπιστωθεί αν είναι γενικό πρόβλημα - πχ. αν και σε άλλες διανομές υπάρχουν τα ίδια προβλήματα
 
Το update στο αρχικό review του Michelangelo λέει τα εξής:

As usual, I started playing my “Raspberry killer” track: a 32 bit, 678 kHz .wav file from my NAS. And… What a terrible disappointment: loads of crackles and a whole lot of lost packets.
Tried then with DSD, 24/192 flacs, and even 16/44.1 flacs. All sounded just terrible. So, indeed the new USB BUS did change USB Audio performances, unfortunately, it did for the worst.

Luckily though, I then tried to play the same files from a USB drive (and not from a NAS), and magic happened: spotless playback up to 32\768. Seemed that taking ethernet (I was connected on wired connection) out of the equation did the trick. So connected the PI via wifi and restarted without ethernet: same result, HI-Res Music playback was just perfect to my USB DAC.

Αυτά είναι καλά νέα, διότι το πρόβλημα είναι γνωστό και κοινο απ ότι φαίνεται και διατηρώ βεβαιότητα ότι θα υπάρξει λύση.



Sent from my MI MAX 2 using Tapatalk
 
Αν δε σερβίρεις τ' αρχεία δικτυακά δεν έχει και μεγάλη σημασία.

Να σημειωθεί ότι δεν έχει τεσταριστεί το wifi στην τελευταία έκδοση και επίσης πως είναι απενεργοποιημένο.

Όποιος θέλει να δοκιμάσει, το ενεργοποιεί από το config.txt, επανεκκινεί και μετά στήνει δίκτυο με τον κλασικό τρόπο:

http://archphile.org/howto/network-configuration
 
Η αναπαραγωγή μέσω ενσύρματου τοπικού δικτύου "ethernet" όντως είναι προβληματική.
Οτιδήποτε πάνω από 24-bit/88.2 ΚΗz ή 24-bit /96KΗz αναπαράγεται με συχνές διακοπές (dropouts).
Τα ίδια προβλήματα επαναλαμβάνονται και με το LibreElec που είναι συμβατό με το RPi3 B+ . Παρεμπιπτόντως τo OpenElec δεν παίζει με το νέο RPi3 B+.

Tuxx, η λύση είναι μία. Να μετατρέψουμε εκείνα τα μουσικά αρχεία, τα οποία είναι ανάλυσης πάνω από 16-bit 48KHz, σε PCM 16-bit 44.1KHz. Ούτως ή άλλως από ένα σημείο και πάνω δεν υπάρχει διαφορά που γίνεται αντιληπτή από τον κοινό μη χαϊεντά άνθρωπο. Ο Lemon μάλιστα, ανακάλυψε προσφάτως ότι με τα XMOS USB to I2S receivers υπάρχει υψηλότερο jitter με τα δείγματα υψηλής ανάλυσης και λιγότερο με τα δείγματα βασικής ανάλυσης 16-bit 44.1KHz.

Στερνή μου γνώση να σ' είχα πρώτα -bye-
 
Το βράδυ θα δοκιμάσω το Volumio και το Moode 4.0 και θα σας πω πως συμπεριφέρεται με τα αρχεία υπερ-υψηλής ανάλυσης, όταν αυτά σερβίρονται από τον NAS server μας.
 
Re: Απάντηση: Archphile - μια audiophile διανομή για Raspberry Pi, Udoo, Cubox-i και

Το βράδυ θα δοκιμάσω το Volumio και το Moode 4.0 και θα σας πω πως συμπεριφέρεται με τα αρχεία υπερ-υψηλής ανάλυσης, όταν αυτά σερβίρονται από τον NAS server μας.

Ο Michelangelo λέει ότι η τελευταία τους έκδοση λύνει κάποια θέματα. Η βασική αλλαγή είναι ο νέος kernel τον οποίον έβαλα και εγώ και δεν είδα καμία διαφορά.

Η λύση βασικά είναι να περιμένουμε να λυθεί με επόμενο driver/kernel.
 
Αν δεν υπάρχει NAS δεν βρίσκω λόγο να ενεργοποιήσει κανείς το WiFi. Για εμένα κάνει ζημιά στον ήχο πόσο μάλλον στο Raspberry.

Επίσης να πούμε πως μιλάμε πάντα για το 3Β+. Στο 3Β το νέο image του Archphile δουλεύει σωστά!
 
Στο επόμενο image για RPI (όταν βρεθεί η λύση στο παραπάνω πρόβλημα δηλαδή) θα γίνει και μια δεύτερη απόπειρα για λίγο σοβαρότερο tweaking.

Μια που δεν μπορώ να ανακατευθύνω τα interrupts από το πρώτο core σε όλα τα υπόλοιπα, σκέφτηκα απλά να απομονώσω το core ώστε να ασχολείται μόνο με αυτά.

Στη συνέχεια θα απομονώσω και το δεύτερο core στο οποίο θα παίζει μπάλα μόνος του ο MPD και τέλος όλα τα ελάχιστα υπόλοιπα θα πηγαίνουν στα cores 3 και 4.

Εδώ φαίνεται η νέα ενεργή γραμμή με isolcpus=0,1:

https://github.com/archphile/recipe/blob/master/files/cmdline.txt

Και εδώ ένα custom archphile-optimize που στέλνει τον mpd στο δεύτερο core και τον ympd στο τρίτο:

https://github.com/archphile/recipe/blob/master/files/archphile-optimize


Με αυτά θεωρώ ότι θα πάμε ένα σκαλί πάνω από θέμα σταθερότητας και απόδοσης. Βέβαια όλα αυτά θα πρέπει να απενεργοποιούνται μαζικά όταν εγκαθίσταται ο mpd-archphile-sacd ο οποίος απαιτεί και τα 4 cores για να δουλέψει σωστά το decoding.
 
Last edited:
Εγω το λεω εφοσον μοιραζεται η erthnet με την usb.... Μηπως κ παιξει καπως καλυτερα σε αποδοση.... Ή τελικα ειναι υπερβολη αυτο που λεω.
 
Όταν ακούς απο USB stick/δίσκο, το ethernet/wifi το χρησιμοποιείς μόνο για αλληλεπίδραση με τον client. Η πιθανότητα αυτό να σου κάνει ακουστή ζημιά είναι ελάχιστη.
 
Στο επόμενο image για RPI (όταν βρεθεί η λύση στο παραπάνω πρόβλημα δηλαδή) θα γίνει και μια δεύτερη απόπειρα για λίγο σοβαρότερο tweaking.

Μια που δεν μπορώ να ανακατευθύνω τα interrupts από το πρώτο core σε όλα τα υπόλοιπα, σκέφτηκα απλά να απομονώσω το core ώστε να ασχολείται μόνο με αυτά.

Στη συνέχεια θα απομονώσω και το δεύτερο core στο οποίο θα παίζει μπάλα μόνος του ο MPD και τέλος όλα τα ελάχιστα υπόλοιπα θα πηγαίνουν στα cores 3 και 4.

Εδώ φαίνεται η νέα ενεργή γραμμή με isolcpus=0,1:

https://github.com/archphile/recipe/blob/master/files/cmdline.txt

Και εδώ ένα custom archphile-optimize που στέλνει τον mpd στο δεύτερο core και τον ympd στο τρίτο:

https://github.com/archphile/recipe/blob/master/files/archphile-optimize


Με αυτά θεωρώ ότι θα πάμε ένα σκαλί πάνω από θέμα σταθερότητας και απόδοσης. Βέβαια όλα αυτά θα πρέπει να απενεργοποιούνται μαζικά όταν εγκαθίσταται ο mpd-archphile-sacd ο οποίος απαιτεί και τα 4 cores για να δουλέψει σωστά το decoding.

με το πρώτο tweak του cmdline.txt απομονώνεται ο core 0 και ο core 1 σωστά;
επίσης η γραμμή υπάρχει στο τελευταίο img ηδη ναι; απλά είναι ανενεργή και πρέπει να μπει και το 0 στο isolcpus=1 δλδ να γίνει isolcpus=0,1 και να ενεργοποιηθεί .. δεν έχει κάποια άλλη διαφορά σε σχέση με το default... τα λέω σωστά;


το δεύτερο που υπάρχει; δεν μπορώ να το βρω. με winSCP δουλεύω...


ακόμα δεν έχω κάνει κάποια αλλαγή βέβαια!

Βασικά εγώ έχω φτιάξει την εντολή στο raspiSSH και στέλνω τον mpd στο C1 όποτε θελήσω... ξέρω πως δεν έχει νόημα με το default setup ... αλλά αν είναι απομονωμένος ίσως έχει!!
 
Last edited:
Αν γίνουν τα παρακάτω, τότε θα είσαι 100% σωστός βάσει όσων είπα παραπάνω:

http://archphile.org/lab/tweaks

Ακόμα καλύτερα, μπορεις να το τρέξεις σαν script, να το κατεβάσεις δηλαδή στο Archphile:

Code:
wget http://archphile.org/lab/tweaks

να το κάνεις εκτελέσιμο:

Code:
chmod +x tweaks

και να το τρέξεις:

Code:
./tweaks

Στο τέλος θέλει ένα reboot.