Raspberry Pi2/Pi3 για audio χρήση - AVClub audio player

nickvas19 said:
με αυτην την εντολη ομως taskset -c -p XXX που οριζεις σε ποιον πυρηνα θα ακουνε;



''Τροποποιήσεις μέσω του μηχανισμού των profiles που αφορούν σε MPDs process priority, CIFs process priority, Kernel scheduler latency και nrpacks.''

αυτο πως το κανεις;μπορεις να μας το αναφερεις;
Click to expand...

Με την εν λόγω εντολή δεν ορίζεις .. τσεκάρεις αν όλα τα PID του MPD τρέχουν σε έναν core .. που αυτό είναι και το ζητούμενο εξ' αρχής!
Να απομονωθεί ο MPD σε έναν core όχι όλες οι διεργασίες του rasp να τρέχουν σε έναν core!
 
Code: 
root@runeaudio(rw):~# taskset -c -p 516
pid 516's current affinity list: 0-2
root@runeaudio(rw):~# taskset -c -p 579
pid 579's current affinity list: 0-2
root@runeaudio(rw):~# taskset -c -p 561
pid 561's current affinity list: 3

τέλικα υπήρχαν και άλλες διεργασίες του MPD που δεν τις έιχα δει που δεν τρέχουν στον core 3 που έχω διαθέσει για τον mpd.... :(
 
Last edited:
Code: 
taskset -c -a -p 3 $(pidof mpd)
με την πιο πάνω εντολή θα τον στείλω στον 3ο;
αυτό πρέπει να δίνεται κάθε φορά που γίνεται reboot η είναι μόνιμη;
 
Code: 
root@runeaudio(rw):~# taskset -c -a -p 3 $(pidof mpd)
pid 493's current affinity list: 3
pid 493's new affinity list: 3
pid 561's current affinity list: 3
pid 561's new affinity list: 3
pid 562's current affinity list: 3
pid 562's new affinity list: 3
pid 563's current affinity list: 3
pid 563's new affinity list: 3
pid 564's current affinity list: 3
pid 564's new affinity list: 3

αυτό δείχνει ΟΚ;
πρέπει να γίνει reboot?

Τα PID 516 και 579 που δεν περιλαμβάνονται στα αποτελέσματα της πιο πάνω εντολής υπάρχει στο htop σαν χρήστης τους ο MPD αλλά στους 0-2 cores παρ όλα αυτά τα εν λόγω PID δεν δείχνουν να μεταβάλονται καθόλου στην λίστα του htop είναι μονόμως σταθερά ενώ τα υπόλοιπα 493, 561, 562, 563, 564 δείχνουν να αλλάζουν συνεχώς... τι παίζει;
Ευχαριστώ!!!
 
Last edited:
εγω δεν καταλαβα πχ το 361 mpd πως βλεπεις σε ποιον πυρηνα τρεχει;

και μετα ποια εντολη θα τον βαλεις σε εναν πυρηνα;

ναι αμα τα ορισεις τα τρεχουν σε εναν πυρηνα που θα διαλεξεις εσυ θα εχει το ιδιο θεμα;
νομιζω πως θα εισαι κομπλε τοτε!
 
Χαιρετώ και εγώ. Μετά από διάβασμα 170 σελίδων είπα να γράψω και εγώ τις απορίες μου για το project.

Έχω Raspberry Pi B το οποίο κάθεται καθώς στη βασική του δουλειά (XBMC) πλέον είναι πολύ αργό.
Θα με ενδιέφερε μια υλοποίηση με I2S DAC καθώς τα αρχεία που έχω είναι το πολύ FLAC.
Αρχικά θα ήθελα να δοκιμάσω με τροφοδοσία από φορτιστή κινητού.

Με βάση τα παραπάνω τι προτείνετε για DAC και OS (ασχολούμαι με Linux δεν υπάρχει θέμα με command line);
 
DomieMic65 said:
Code: 
taskset -c -a -p 3 $(pidof mpd)
με την πιο πάνω εντολή θα τον στείλω στον 3ο;
αυτό πρέπει να δίνεται κάθε φορά που γίνεται reboot η είναι μόνιμη;
Click to expand...


Με αυτή την εντολή θα μπουν στο 4ο core όλα τα processes του MPD.

Δεν είναι μόνιμη εντολή και θέλει να τρέχει σε κάθε εκκίνηση. Αυτό που κάνω στο Archphile, είναι ότι έχω ένα service (το archphile.service), το οποίο στην εκκίνηση του συστήματος τρέχει ένα script. Στο script αυτό υπάρχουν διάφορες εντολές. Αυτό που έχω κάνει στο odroid αυτή τη στιγμή είναι το εξής:

1. Έχω απομονώσει τα cores 2,3,4 με το κατάλληλο config στο /boot/boot.ini και πιο συγκεκριμένα με την προσθήκη του isolcpus=1,2,3
2. Στο script που τρέχει κατά την εκκίνηση έχω τις εξής γραμμές που αφορούν στα όσα λέμε:

Code: 
# IRQ affinity optimization - Do not apply it if you have a Raspberry Pi!!!
#
/usr/bin/irq-archphile

# set various processes to be run on specific cores
# enabling all of these lines is not a very good idea
#
taskset -c -a -p 1 $(pidof mpd)
taskset -c -p 0 $(pidof ympd)
taskset -c -a -p 0 $(pidof librespot)
taskset -c -p 0 $(pidof lircd)


Εδώ λοιπόν κατά το boot, αρχικά εκτελείται μια εντολή με όνομα irq-archphile. Αυτό είναι ένα άλλο script το οποίο κατανέμει τα interrupts στo τρίτο και στο τέταρτο core. To περιεχόμενο του irq-archphile είναι το παρακάτω:

Code: 
#!/bin/bash
# Cores 1 2 3 4 have to be put as 1 2 4 8

# USB bus
echo "8" > /proc/irq/62/smp_affinity
echo "8" > /proc/irq/63/smp_affinity

# Ethernet
echo "4" > /proc/irq/40/smp_affinity


Στη συνέχεια τρέχει η πρώτη εντολή taskset η οποία βάζει sto δέυτερο core ότι σχετίζεται με τον mpd. Το pidof mpd πιάνει και το PID του ympd που τρέχει στο archphile και το βάζει επισης στο δεύτερο core, οπότε με το επόμενο taskset επανατοποθετείται στο πρώτο core. Μετά τρέχουν ακόμα δύο taskset, ένα για το spotify και ένα για το lirc.

Να σημειωθεί ότι όταν γίνεται isolate ένα core, συνεχίζουν να πέφτουν interrupts πάνω του.
 
svizi said:
Χαιρετώ και εγώ. Μετά από διάβασμα 170 σελίδων είπα να γράψω και εγώ τις απορίες μου για το project.

Έχω Raspberry Pi B το οποίο κάθεται καθώς στη βασική του δουλειά (XBMC) πλέον είναι πολύ αργό.
Θα με ενδιέφερε μια υλοποίηση με I2S DAC καθώς τα αρχεία που έχω είναι το πολύ FLAC.
Αρχικά θα ήθελα να δοκιμάσω με τροφοδοσία από φορτιστή κινητού.

Με βάση τα παραπάνω τι προτείνετε για DAC και OS (ασχολούμαι με Linux δεν υπάρχει θέμα με command line);
Click to expand...

Όσο αφορά το όλο σύστημα, αν η προτεραιότητά σου είναι το VFM αλλά με την καλύτερη δυνατή ποιότητα ήχου, θα πρότεινα να πάρεις ένα Boss DAC.

Υποστηρίζεται κανονικά από το Volumio και σιγά σιγά μπαίνει και στις άλλες audio διανομές.

Θα παίξει πολύ καλά ακόμα και με ένα φορτιστή κινητού.
 
''Τροποποιήσεις μέσω του μηχανισμού των profiles που αφορούν σε MPDs process priority, CIFs process priority, Kernel scheduler latency και nrpacks.''

τα βηματα για ολα αυτα ...υπαρχουν καπου συγκεντρωμενα;

πως θα κανω ολα τα service του mpd να τρεξουν; διοτι εχω μονο 3 βλεπω! και δεν μ αφηνει να τα πειραξω!

ευχαριστω

ps: έχει βγει ακρη για το spotify?!
 
Δημήτρης Δημητρακούδης said:
Σας διαβάζω και από τη μια χαίρομαι που εξ' αιτίας του audio στο RPi θα γίνετε σωστοί Linux admins, από την άλλη δεν μπορώ παρά να απορώ με τη σπατάλη χρόνου.. :p
Click to expand...

Να προσέξεις μη βραχυκυκλώσεις :p
Χωρίς εσενα δεν ξερω με τι θα ακουγαν πολλοί απο εδω μέσα (μεχρι και εμενα με επεισες να αγοράσω dac που ειμαι κανιβαλος φίλος του πολυκάναλου) :music-smiley-005:
 
Δημήτρης Δημητρακούδης said:
Σας διαβάζω και από τη μια χαίρομαι που εξ' αιτίας του audio στο RPi θα γίνετε σωστοί Linux admins, από την άλλη δεν μπορώ παρά να απορώ με τη σπατάλη χρόνου.. :p
Click to expand...
Κοινώς εννοείς πως χάνουμε τον χρόνο μας για ανούσια πράγματα;
:)

Sent from my Nexus 5X
 
Δημήτρης Δημητρακούδης said:
Σας διαβάζω και από τη μια χαίρομαι που εξ' αιτίας του audio στο RPi θα γίνετε σωστοί Linux admins, από την άλλη δεν μπορώ παρά να απορώ με τη σπατάλη χρόνου.. :p
Click to expand...

Δεν έχεις κι άδικο …
Θα προτιμούσα να ασχοληθώ π.χ. με τα LXmini+2 αλλά χωρίς χέρι βοήθειας, μόνος μου δεν …
Πάντως βλέποντας το ότι η Bryston μας αντέγραψε, μου κάνει κάπως παρήγορο…
 
FragoulisNaval said:
Να πάρετε MUSIChi να σωθείτε

Στάλθηκε από το X9007 μου χρησιμοποιώντας Tapatalk
Click to expand...

Θα πάρουμε και ένα mini pc με 200-300 στην καλύτερη. Μετά δε θα μας κάνει το τροφοδοτικό και θα βάλουμε να μας φτιάξουν κανα γραμμικό και θα σκάσουμε καμια κατοστάρα ακόμα. Μετά θα ζεσταίνεται το πισάκι και θα κάνει θόρυβο και θα ψάχνουμε καλά ανεμιστήρια ή καμια passive θήκη και αφού τα λύσουμε όλα αυτά θα πάρουμε και ένα fidelizer plus με 40 δολλάρια αλλά θα μας τρώει να δοκιμάσουμε και το fidelizer pro που κάνει καμιά 30ριά ακόμα και κάνει black box optimization. Και μετά... Και μετά.... Και μετά......


Και αφού τα κάνουμε όλα αυτά και γράφουμε σελίδες επί σελίδων σε ένα τόπικ σαν αυτό, θα μπει κάποιος στο ξαφνικό και θα μας πει να πάρουμε ένα Odroid C2 με Linux/MPD για να "σωθούμε". Και φτου.... Πάλι από την αρχή.


Για να σοβαρευτώ, αυτό που προσπαθούν να κάνουν τα παιδιά εδώ και κάποιες σελίδες, δε διαφέρει σε τίποτα από όλα τα optimizations που διαφημίζει το κάθε fidelizer.. Ή μάλλον τώρα που το σκέφτομαι καλύτερα διαφέρει, γιατί τα παιδιά θα παιδευτούν λιγάκι και θα μάθουν και κάτι και στην τελική θα έχουν περιποιηθει με τα χεράκια τους το transport τους και μεθαύριο θα μπορούν να στήσουν και ένα high end pc transport με super duper χαρακτηριστικά κομμένο και ραμμένο στα χέρια τους.


Στο θέμα μας τώρα. Όλο το optimization που κάνετε όσοι προσπαθείτε, έχει μια βασική προυπόθεση. Αυτή είναι το να ξέρετε τι ήδη έχει κάνει η ομάδα του Runeaudio. Όλα αυτά τα profιiles που προεπιλέγετε είναι πιθανόν να έχουν αντικρουόμενες ρυθμίσεις με αυτές που προσπαθείτε να βάλετε εσείς. Επίσης υπάρχει περίπτωση εσείς να κάνετε μια ρύθμιση η οποία αναιρείται γιατί αμέσως μετά την εντολή σας τρέχει ένα συστημικό script και τα αλλάζει όλα αυτά.

Σας έχω αναφέρει σε πολλά posts ότι το RPI δεν δέχεται IRQ affinity optimization και δεν έχετε δώσει βάση. Αυτό τι σημαίνει; Σημαίνει ότι τα interrupts που σκάνε στα 4 cores από τις διάφορες συσκευές και υποσυστήματα (USB, ethernet, SD card κλπ) δεν μπορούν να αναδρομολογηθούν στο core που θέλετε εσείς (όπως συμβαίνει πχ σε ένα pc ή σε πολλά άλλα boards). Κατ επέκταση, αυτό που έδειξα παραπάνω, όπου ένα script αναδρομολογεί τα interrupts του USB πχ στο 4o core δεν μπορεί να γίνει. Ότι interrupt πέφτει πχ στο 4ο core, θα πέφτει πάντα εκεί.

Ως συνέπεια του παραπάνω, το πρώτο πράγμα που θα κοιτούσα εγώ αν σώνει και καλά ήθελα να ρίξω καρφωτά τον mpd και τα threads του σε ένα isolated core, θα ήταν αυτό το core να δέχεται τα λιγότερα δυνατά interrupts. To γεγονός ότι το απομονώνετε δε σημαίνει ότι δεν πέφτουν interrupts.

Πως γίνεται αυτό;;

Code: 
cat /proc/interrupts

Με την εντολή αυτή θα δείτε τι πέφτει ανά core. Εγώ λοιπόν θα έτρεχα αυτή την εντολή μην έχοντας κάνει optimization στο σύστημά μου, θα παρακολουθούσα τι συμβαίνει και μετά θα αποφάσιζα ποιο core θα "τάξω" στον MPD.

Κάτι τελευταίο. Να ξέρετε ότι με όλα αυτά, ενδέχετε να προσπαθείτε να κάνετε καλό και να τα κάνετε μαντάρα. Αν ανατρέξετε σε παλιά μου posts και στο νήμα αυτό αλλά και στου Archphile, θα δείτε ότι παλεύω μήνες με αυτά για το επόμενο Archphile. Υπάρχει όμως μια ΜΕΓΑΛΗ διαφορά. Στο Archphile ούτε web server τρέχω, ούτε mysql server ούτε php-fpm, ούτε..., ούτε... κλπ... Έχω πραγματικά ελάχιστα processes και παίζω μπάλα δεξιά και αριστερά να τα βολέψω στα διαθέσιμα cores. Εσείς έχετε ΠΟΛΛΑ processes και δεν μπορείτε να ξέρετε πως θα συμπεριφερθεί το σύστημά σας τελικά αν τα στριμώξετε όλα σε ένα core ή δεν ξέρω και γω τι άλλο κάνετε.

Εγώ απλά θα σας πώ, ότι με τερματισμένο υποτίθεται optimization που είχα ανακατεθύνει σχεδόν κάθε process εκεί που θεωρούσα ότι είναι και σωστό, κατέληξα σε ένα test σύστημα όπου έδινα εντολή ssh και άκουγα "κλικ" από τα ηχεία. Είναι πολύ πιθανότερο ο scheduler ενός OS να κάνει καλύτερες επιλογές απ' ότι αν μαζευτούμε 5 άμπαλοι μαζί και να ρίχνουμε ιδέες που θα ήταν καλύτερα να σκάει το τάδε interrupt ή το δείνα process!


Αυτά είχα να πω.

Καλή συνέχεια στο κάψιμο και στην αναζήτησή σας. Το "σκάλισμα" δεν έβλαψε κανέναν!
 
Ρε συ Φραγκούλη, πραγματικά δεν έχω τίποτε με το musichi. Ίσα ίσα γνώρισα τον άνθρωπο που το γράφει στην έκθεση και είναι και συμπαθέστατος.

Δε γίνεται όμως να μπαίνεις σε νήμα που αφορά το RPI και κατά 99% και τον MPD και να μας λες για server/client εν έτει 2017 :D :D :D


O MPD βασίζεται σε λογική server/client τα τελευταία 14 χρόνια...

https://en.wikipedia.org/wiki/Music_Player_Daemon
 
Top Bottom