MPD (Music Player Daemon)

Messaggio da **Miclaud** » 05 dic 2013, 16:51

UnixMan ha scritto:Casomai vi fosse sfuggito, nel repository Voyage experimental è disponibile una nuova versione di MPD (0.18.4git) con la patch RT:
* new upstream release from git
* backported Yan's patch : mpd-rtopt-20130203.diff for 0.18.4
http://www.voyage.hk/dists/experimental ... 86.changes

Ciao a tutti! E' un po' che non ci sentiamo

Finalmente ho avuto il tempo di fare un po' di prove serie da un mio amico, con risultati molto interessanti.

Posso prima di tutto dirvi che il kernel realtime fa la differenza, e non poco! Maggior profondità, limpidezza e suono molto più raffinato e dalla grana fine. Perdonate i termini da "sommelier audiofilo" ma sono le stesse sensazioni che ho avuto quando sono passato ad alimentazioni lineari, un miglioramento davvero sensibile, ammetto che non ci speravo così tanto.
Poi ho avuto anche modo di apprezzare le qualità dell'upsampling con libsoxr. Purtroppo il mio Geode non vanta grandi prestazioni: spesso nei primi istanti del playback avvengono dei salti, proprio in occasione del picco iniziale della CPU, dovuto probabilmente al caricamento del file audio in memoria e all'avvio delle prime elaborazioni. Poi la situazione si stabilizza, ma è piuttosto fastidioso. In ogni caso, questo problema è quasi assente se provo frequenze di campionamento che sono multipli dei file trattati. Usando quindi un campionamento di 88.2 khz con file da 44.1, le cose vanno benone. Son dolori invece quando provo ad upsamplare gli stessi a 48, 96 o peggio ancora 192.

Che voi sappiate, c'è modo di dire a MPD di usare una frequenza di campionamento relativa al file trattato? Mi sembra che in Foobar fosse possibile dire di moltiplicare per 2 o per 4 le frequenze dei file in ingresso, il che permetterebbe sempre di sovracampionare a frequenze direttamente multiple, evitando conversioni "strane" e difficili da trattare.

Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?

Messaggio da **UnixMan** » 05 dic 2013, 17:52

Miclaud ha scritto:Posso prima di tutto dirvi che il kernel realtime fa la differenza, e non poco!

con che setup? hai applicato questi settings?

Miclaud ha scritto:Purtroppo il mio Geode non vanta grandi prestazioni: spesso nei primi istanti del playback avvengono dei salti, proprio in occasione del picco iniziale della CPU, dovuto probabilmente al caricamento del file audio in memoria e all'avvio delle prime elaborazioni.

prova a ridurre il buffering iniziale di MPD.

Miclaud ha scritto:Che voi sappiate, c'è modo di dire a MPD di usare una frequenza di campionamento relativa al file trattato?

purtroppo, che io sappia no.

Miclaud ha scritto:Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?

provo e ti faccio sapere...

Messaggio da **sontero** » 05 dic 2013, 21:51

Miclaud ha scritto:
Ciao a tutti! E' un po' che non ci sentiamo
Finalmente ho avuto il tempo di fare un po' di prove serie da un mio amico, con risultati molto interessanti.

Posso prima di tutto dirvi che il kernel realtime fa la differenza, e non poco! Maggior profondità, limpidezza e suono molto più raffinato e dalla grana fine. Perdonate i termini da "sommelier audiofilo" ma sono le stesse sensazioni che ho avuto quando sono passato ad alimentazioni lineari, un miglioramento davvero sensibile, ammetto che non ci speravo così tanto.
Poi ho avuto anche modo di apprezzare le qualità dell'upsampling con libsoxr. Purtroppo il mio Geode non vanta grandi prestazioni: spesso nei primi istanti del playback avvengono dei salti, proprio in occasione del picco iniziale della CPU, dovuto probabilmente al caricamento del file audio in memoria e all'avvio delle prime elaborazioni. Poi la situazione si stabilizza, ma è piuttosto fastidioso. In ogni caso, questo problema è quasi assente se provo frequenze di campionamento che sono multipli dei file trattati. Usando quindi un campionamento di 88.2 khz con file da 44.1, le cose vanno benone. Son dolori invece quando provo ad upsamplare gli stessi a 48, 96 o peggio ancora 192.

Che voi sappiate, c'è modo di dire a MPD di usare una frequenza di campionamento relativa al file trattato? Mi sembra che in Foobar fosse possibile dire di moltiplicare per 2 o per 4 le frequenze dei file in ingresso, il che permetterebbe sempre di sovracampionare a frequenze direttamente multiple, evitando conversioni "strane" e difficili da trattare.

Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?

Ciao Miclaud. Le tue osservazioni sono sostanzialmente simili a quelle che ho sperimentato nel mio sistema per quanto riguarda le prestazioni all'ascolto, quindi siamo almeno in due ad aver relazionato molto positivamente.
Nel mio sistema se provo a upsamplare non ho nessun problema ,fila liscio (ho un thin client con CPU VIA 7 da 1Ghz) pero' ho riscontrato lo stesso tuo problema muovendo la barra di esecuzione,anche a me crasha e devo riavviare MPD (non mi toglie il sonno comunque questo problema....) francamente non sento l'esigenza di cambiare con l'ultima versione indicata da Paolo perchè mi sta andando tutto a meraviglia (ho anche applicato i settings per il K RT) .

Messaggio da **antonellocaroli** » 06 dic 2013, 09:54

Miclaud ha scritto:
UnixMan ha scritto:Casomai vi fosse sfuggito, nel repository Voyage experimental è disponibile una nuova versione di MPD (0.18.4git) con la patch RT:
* new upstream release from git
* backported Yan's patch : mpd-rtopt-20130203.diff for 0.18.4
http://www.voyage.hk/dists/experimental ... 86.changes

Ciao a tutti! E' un po' che non ci sentiamo
Finalmente ho avuto il tempo di fare un po' di prove serie da un mio amico, con risultati molto interessanti.

Posso prima di tutto dirvi che il kernel realtime fa la differenza, e non poco! Maggior profondità, limpidezza e suono molto più raffinato e dalla grana fine. Perdonate i termini da "sommelier audiofilo" ma sono le stesse sensazioni che ho avuto quando sono passato ad alimentazioni lineari, un miglioramento davvero sensibile, ammetto che non ci speravo così tanto.
Poi ho avuto anche modo di apprezzare le qualità dell'upsampling con libsoxr. Purtroppo il mio Geode non vanta grandi prestazioni: spesso nei primi istanti del playback avvengono dei salti, proprio in occasione del picco iniziale della CPU, dovuto probabilmente al caricamento del file audio in memoria e all'avvio delle prime elaborazioni. Poi la situazione si stabilizza, ma è piuttosto fastidioso. In ogni caso, questo problema è quasi assente se provo frequenze di campionamento che sono multipli dei file trattati. Usando quindi un campionamento di 88.2 khz con file da 44.1, le cose vanno benone. Son dolori invece quando provo ad upsamplare gli stessi a 48, 96 o peggio ancora 192.

Che voi sappiate, c'è modo di dire a MPD di usare una frequenza di campionamento relativa al file trattato? Mi sembra che in Foobar fosse possibile dire di moltiplicare per 2 o per 4 le frequenze dei file in ingresso, il che permetterebbe sempre di sovracampionare a frequenze direttamente multiple, evitando conversioni "strane" e difficili da trattare.

Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?

Puoi postare il tuo mpd.conf?

Messaggio da **antonellocaroli** » 07 dic 2013, 09:39

kartak ha scritto:Salve a tutti
le ultime patch rt per mpd le trovate qui....

https://skydrive.live.com/?cid=CE384832 ... 8DA832!105

Ciao Kartak,
matu sei riuscito ad applicare una di quelle patch?

Messaggio da **Miclaud** » 07 dic 2013, 10:02

UnixMan ha scritto: con che setup? hai applicato questi settings?

Non riesco a seguire il link che mi hai indicato, comunque il mio mpd è questo:

Codice: Seleziona tutto


auto_update     "yes"
auto_update_depth       "6"


realtime_option {
        memlock "yes"
        stack_reserve "1024"
        heap_reserve "0"

        main_priority "OTHER:0"
        player_priority "FIFO:49"
        decoder_priority "FIFO:48"
        update_priority "OTHER:0"
}

audio_output {
        type "alsa"
        name "AQUA XMOS"
        device "hw:0,0"
        priority "FIFO:48"
        auto_resample "yes"
        format "88200:24:2"
        use_mmap "yes"
}

samplerate_converter            "SoX VHQ"



filesystem_charset		"UTF-8"
id3v1_encoding			"UTF-8"

follow_outside_symlinks "yes"
follow_inside_symlinks "yes"

zeroconf_enabled "yes"
zeroconf_name "Voyage Music Player"

mixer_type "disabled"
bind_to_address "0.0.0.0"

audio_buffer_size               "1600"
buffer_before_play              "100%"

Come potete notare "audio_buffer_size" è piccolissimo. E' l'unico modo per poter usare Sox con un minimo di resa, anche se occasionalmente ci sono ancora problemi di salti.

Notate inoltre come la priorità rt del thread "audio" sia a 48, come il thread "decoder". In questo modo, se non ho capito male, il thread con più priorità è "player". Abbiamo provato ad impostare "audio" come thread con maggior priorità ma abbiamo notato che la qualità del suono era leggermente inferiore, seppur sempre ottima.

Si potrebbero fare altre prove, magari non usando lo scheduling FIFO. Che voi sappiate, esiste una documentazione che spiega bene quali siano i compiti dei singoli thread di MPD (player, decoder, audio...)?
Potremmo provare a realizzare insieme una sorta di piccolo vademecum su come sperimentare le varie impostazioni

sontero ha scritto: Nel mio sistema se provo a upsamplare non ho nessun problema ,fila liscio (ho un thin client con CPU VIA 7 da 1Ghz)

Avevo dimenticato questo particolare, ho anche un thinclient di un amico con il tuo stesso processore. Confermo, nessun problema in questo caso, il picco iniziale si ferma intorno al 60%. Posso upsamplare a qualsiasi frequenza, anche da 44.1/16 a 192/32.

Una prova che farò in futuro sarà paragonare le due schede madri: Alix + Geode 500Mhz da un lato e Thinclient + Via C7 1Ghz dall'altro. Il Geode è fantastico per i suoi bassissimi consumi, tanto per dire non ha neanche un dissipatore sulla CPU, al contrario del VIA il quale se non altro riesce comunque a rinunciare alle ventole. Alix sembra di un livello qualitativo generalmente superiore, ad occhio, ma sarà interessante vedere se ci saranno differenze percepibili sul suono. Devo solo metterli in condizione di eseguire lo stesso sistema operativo e sfruttare la stessa alimentazione

Vi informerò al rigaurdo.

Messaggio da **UnixMan** » 07 dic 2013, 11:37

UnixMan ha scritto:
Miclaud ha scritto:Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?
provo e ti faccio sapere...

No, a me non da problemi di sorta (mpd 0.18.4git con patch RT da Voyage experimental su Debian 32bit, client gmpc).

Messaggio da **Miclaud** » 07 dic 2013, 12:38

UnixMan ha scritto:
UnixMan ha scritto:
Miclaud ha scritto:Inoltre con questa versione patchata di mpd (si quella appena uscita, quotata qui sopra, che la precedente) ho grossi problemi nello spostare l'esecuzione da un punto a l'altro del brano. Come provo a spostare la barra di esecuzione in un altro punto del brano MPD crasha e non posso far altro che riavviarlo. Per voi è lo stesso?
provo e ti faccio sapere...
No, a me non da problemi di sorta (mpd 0.18.4git con patch RT da Voyage experimental su Debian 32bit, client gmpc).

Argh...

Ti ringrazio. Posso chiederti su quale hardware gira il tutto? A cosa ti riferisci con Voyage Experimental? La daily snapshot dal sito di voyage?

Messaggio da **UnixMan** » 07 dic 2013, 13:19

Miclaud ha scritto:Non riesco a seguire il link che mi hai indicato,

sorry, link errato.

Quello giusto è questo: http://www.audiofaidate.org/forum/viewt ... 61#p119161 (post precedente qui).

Miclaud ha scritto:Come potete notare "audio_buffer_size" è piccolissimo.

IMHO, è sbagliato: è il "buffer_before_play" che deve essere mooolto più basso, lasciando invece le dimensioni complessive del buffer sui valori consigliati. Per cominciare, io proverei a commentare quelle due righe in modo che vengano adottati i valori di default...

Miclaud ha scritto:Notate inoltre come la priorità rt del thread "audio" sia a 48, come il thread "decoder". In questo modo, se non ho capito male, il thread con più priorità è "player". Abbiamo provato ad impostare "audio" come thread con maggior priorità ma abbiamo notato che la qualità del suono era leggermente inferiore, seppur sempre ottima.

hai provato a mettere tutti e tre alla stessa priorità?
ad usare la modalità RT "RR" anziché quella "FIFO"?
a spostare la priorità RT dei processi di mpd a valori più bassi / uguali / più alti rispetto ai processi RT del kernel? (priorità RT=50)

N.B.: verifica con "htop" (o simili) l'effettiva priorità assegnata ai processi!

P.S.: ho notato che non è necessario specificare "priority" all'interno delle definizioni della/e uscita/e audio: omettendo il parametro, la priorità viene assegnata automaticamente ad un valore uguale a quella del processo "player". Al momento sto provando così:

Codice: Seleziona tutto

realtime_option {
memlock "yes"
stack_reserve "1024"
heap_reserve "0"
main_priority "OTHER:0"
update_priority "OTHER:0"
decoder_priority "RR:59"
player_priority "RR:59"
}

Miclaud ha scritto:Si potrebbero fare altre prove, magari non usando lo scheduling FIFO.

infatti. IMHO, almeno in teoria dovrebbe essere meglio utilizzare "RR".

Miclaud ha scritto:Potremmo provare a realizzare insieme una sorta di piccolo vademecum su come sperimentare le varie impostazioni

mi sembra una buona idea.

Miclaud ha scritto:Ti ringrazio. Posso chiederti su quale hardware gira il tutto?

Al momento, un Intel Core2 duo E5200.

Miclaud ha scritto:A cosa ti riferisci con Voyage Experimental?

http://www.voyage.hk/dists/experimental/mpd/

Messaggio da **antonellocaroli** » 08 dic 2013, 12:35

Ciao,

qualcuno ha provato a suonare qualche play list da soundcloud?

Io ho questo problema...la playlist parte, ma dopo pochi minuti é il silenzio.

questo dopo che do mpd restart:

Codice: Seleziona tutto

Stopping Music Player Daemon: mpd.
[....] Starting Music Player Daemon: mpdrtopt: realtime_option(set_parameter): memlock enable  stack_reserve : 1048576   heap_reserve : 0
rtopt: realtime_option(set_parameter): main_priority  policy 0  priority 0
rtopt: realtime_option(set_parameter): player_priority  policy 1  priority 50
rtopt: realtime_option(set_parameter): decoder_priority  policy 1  priority 70
rtopt: realtime_option(set_parameter): update_priority  policy 0  priority 0
rtopt: realtime_option(init_output_priority_tab): output priority name My Alsa policy 1  priority 95
rtopt: realtime_option(init_output_priority_tab): output priority name MPD upsample policy 1  priority 95
rtopt: realtime_option(init_output_priority_tab): output priority name SOX upsample policy 1  priority 95
rtopt: realtime_option(rtopt_change_priority): name main_priority   policy 0  priority 0
rtopt: realtime_option(rtopt_change_thread_priority): name main_priority not changed
path: SetFSCharset: fs charset is: UTF-8
libsamplerate: libsamplerate converter 'SoX VHQ'
opus: libopus 0.9.14
db: reading DB
soundcloud: disabling the soundcloud playlist plugin because API key is not set
daemon: opening pid file
daemon: daemonized
daemon: writing pid file

Questo nel log:

Codice: Seleziona tutto

Dec 08 13:34 : state_file: Saving state file /var/lib/mpd/state
Dec 08 13:34 : output: closed plugin=alsa name="MPD upsample"
Dec 08 13:34 : avahi: Shutting down interface
Dec 08 13:34 : listen: listen_global_finish called
Dec 08 13:34 : client: [1] closed
Dec 08 13:34 : main: db_finish took 0.070000 seconds
Dec 08 13:34 : avahi: Initializing interface
Dec 08 13:34 : avahi: Client changed to state 2
Dec 08 13:34 : avahi: Client is RUNNING
Dec 08 13:34 : avahi: Registering service _mpd._tcp/Voyage Music Player
Dec 08 13:34 : avahi: Service group changed to state 0
Dec 08 13:34 : avahi: Service group is UNCOMMITED
Dec 08 13:34 : state_file: Loading state file /var/lib/mpd/state
Dec 08 13:34 : rtopt: realtime_option(rtopt_change_priority): name player_priority   poli                                                                                                                                                    cy 1  priority 50
Dec 08 13:34 : rtopt: realtime_option(change_priority): name player_priority  policy 1                                                                                                                                                       priority 50
Dec 08 13:34 : rtopt: realtime_option(rtopt_change_priority): name decoder_priority   pol                                                                                                                                                    icy 1  priority 70
Dec 08 13:34 : rtopt: realtime_option(change_priority): name decoder_priority  policy 1                                                                                                                                                       priority 70
Dec 08 13:34 : rtopt: realtime_option(rtopt_change_output_priority): name MPD upsample                                                                                                                                                       policy 1  priority 95
Dec 08 13:34 : rtopt: realtime_option(change_priority): name MPD upsample  policy 1   pri                                                                                                                                                    ority 95
Dec 08 13:34 : inotify: initializing inotify
Dec 08 13:34 : inotify: watching music directory
Dec 08 13:34 : rtopt: realtime_option(rtopt_memlock): stack_reserve 1048576
Dec 08 13:34 : avahi: Service group changed to state 1
Dec 08 13:34 : avahi: Service group is REGISTERING
Dec 08 13:34 : client: [0] opened from 192.168.178.21:50056
Dec 08 13:34 : client: [0] process command "idle"
Dec 08 13:34 : client: [0] command returned 1
Dec 08 13:34 : client: [0] closed
Dec 08 13:34 : client: [1] opened from 192.168.178.21:50058
Dec 08 13:34 : client: [1] process command "idle"
Dec 08 13:34 : client: [1] command returned 1
Dec 08 13:34 : decoder_thread: probing plugin mad
Dec 08 13:34 : mad: detected LAME version 3.99 ("LAME3.99r")
Dec 08 13:34 : mad: LAME peak found: 0.000000
Dec 08 13:34 : mad: LAME track gain found: -5.900000
Dec 08 13:34 : mad: encoder delay is 576, encoder padding is 832
Dec 08 13:34 : decoder: audio_format=44100:24:2, seekable=true
Dec 08 13:34 : avahi: Service group changed to state 2
Dec 08 13:34 : avahi: Service 'Voyage Music Player' successfully established.
Dec 08 13:34 : alsa_output: opened hw:0,0 type=HW
Dec 08 13:34 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Dec 08 13:34 : alsa_output: buffer: size=8..131072 time=41..682667
Dec 08 13:34 : alsa_output: period: size=8..131072 time=41..682667
Dec 08 13:34 : alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
Dec 08 13:34 : alsa_output: buffer_size=96000 period_size=24000
Dec 08 13:34 : output: opened plugin=alsa name="MPD upsample" audio_format=192000:32:2
Dec 08 13:34 : output: converting from 44100:24:2
Dec 08 13:34 : libsamplerate: setting samplerate conversion ratio to 4.35
Dec 08 13:34 : client: [1] process command "idle"
Dec 08 13:34 : client: [1] command returned 1
Dec 08 13:34 : client: [2] opened from 192.168.178.21:50061
Dec 08 13:34 : client: [2] process command "status"
Dec 08 13:34 : client: [2] command returned 0
Dec 08 13:34 : client: [2] process command "replay_gain_status"
Dec 08 13:34 : client: [2] command returned 0
Dec 08 13:34 : client: [1] process command "idle"
Dec 08 13:34 : client: [1] command returned 1
Dec 08 13:34 : client: [2] process command "status"
Dec 08 13:34 : client: [2] command returned 0
Dec 08 13:34 : client: [2] process command "replay_gain_status"
Dec 08 13:34 : client: [2] command returned 0
Dec 08 13:35 : client: [2] timeout
Dec 08 13:35 : client: [2] closed

Comunque a quanto pare é un problema con l´ultima versione in Experimental....domani gli scrivo.

kartak · Messaggio da **kartak** » 08 dic 2013, 22:25

antonellocaroli ha scritto:
kartak ha scritto:Salve a tutti
le ultime patch rt per mpd le trovate qui....

https://skydrive.live.com/?cid=CE384832 ... 8DA832!105

Ciao Kartak,
matu sei riuscito ad applicare una di quelle patch?

Si...questa è l ultima versione 0.18.5 con la patch Rt...risotta al minimo...molte opzioni sono disattivate....

mediafire.com/download/zx9p6ruc4c9669r/RT+mpd_0.18.5-1_i386.rar

Installa le dipendenze di mpd...
Installa il pacchetto deb
Sposta il file mpd da /usr/local/bin a usr/bin/

Occhio che la cartella playlists....in var lib mpd...viene cancellata...

Questo è il mio config

./configure --disable-adplug --disable-roar --disable-ao --disable-audiofile --disable-bzip2 --disable-cdio-paranoia --disable-curl --disable-debug --disable-documentation --disable-fifo --disable-fluidsynth --disable-gme --disable-httpd-output --disable-inotify --disable-ipv6 --disable-iso9660 --disable-jack --disable-despotify --disable-soundcloud --disable-lame-encoder --disable-libwrap --disable-lsr --disable-mad --disable-mikmod --disable-mms --disable-modplug --disable-mpc --disable-mpg123 -disable-openal --disable-oss --disable-opus --disable-pipe-output --disable-pulse --disable-recorder-output --disable-sidplay --disable-shout --disable-sndfile --disable-solaris-output --disable-sqlite --disable-test --disable-twolame-encoder --disable-vorbis --disable-vorbis-encoder --disable-wave-encoder --disable-wavpack --disable-werror --disable-wildmidi --disable-zzip --disable-aac --enable-rtopt

Messaggio da **antonellocaroli** » 09 dic 2013, 17:41

UnixMan ha scritto:
P.S.: ho notato che non è necessario specificare "priority" all'interno delle definizioni della/e uscita/e audio: omettendo il parametro, la priorità viene assegnata automaticamente ad un valore uguale a quella del processo "player". Al momento sto provando così:
Codice: Seleziona tutto
realtime_option {
memlock "yes"
stack_reserve "1024"
heap_reserve "0"
main_priority "OTHER:0"
update_priority "OTHER:0"
decoder_priority "RR:59"
player_priority "RR:59"
}

Ciao Paolo,
volendo non usare una versione di mpd Patchata,
come si fa a dare quelle prioritá?

Messaggio da **UnixMan** » 09 dic 2013, 18:19

antonellocaroli ha scritto:volendo non usare una versione di mpd Patchata,
come si fa a dare quelle prioritá?

Puoi usare il comando "chrt" oppure "schedtool" (lo avevo già accennato nel post sul RT).

Puoi lanciare mpd direttamente "attraverso" chrt (o schedtool), oppure modificare scheduling e priorità di qualsiasi processo già esistente. Ovviamente, se lanci mpd direttamente con chrt (o schedtool), tutti i (sotto)processi/thread avranno la medesima priorità (incluso quelli che sarebbe meglio lasciare a bassa priorità, tipo gli aggiornamenti della libreria).

Conviene quindi agire "a posteriori", identificando i "pid" dei vari (sotto)processi di mpd e cambiandone scheduling e priorità uno per uno.

La cosa ovviamente può essere automatizzata con uno script che poi puoi far eseguire subito dopo l'avvio di mpd dallo stesso init script di mpd, oppure avviare alla fine del boot aggiungendolo alla fine di /etc/rc.local.

Messaggio da **antonellocaroli** » 09 dic 2013, 20:01

UnixMan ha scritto: Conviene quindi agire "a posteriori", identificando i "pid" dei vari (sotto)processi di mpd e cambiandone scheduling e priorità uno per uno.

ecco é proprio questo il problema come identificare quei "pid" ?

Dando un comando del genere
chrt -f -p 45 `pgrep mpd`

significa dare prioritá 45 a MPD e a tutti i sottoprocessi...

ma se si vuole sostiture quello che si scrive nel mpd.conf é basta?

Messaggio da **UnixMan** » 10 dic 2013, 14:09

Devi realizzare uno script un po' più complesso. Per cominciare, è necessario identificare i diversi thread di mpd, ad es. così:

Codice: Seleziona tutto

$ ps -C mpd -Lfc
UID        PID  PPID   LWP NLWP CLS PRI STIME TTY          TIME CMD
mpd      30288     1 30288    5 TS   19 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30291    5 TS   19 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30293    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30294    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30295    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf

quindi puoi usare "chrt -p nn xxxxx" per impostare la priorità dei diversi thread.

BTW: sempre a proposito di RT, per caso ho visto questo: https://sites.google.com/site/computera ... ng-up-alsa

ci stavo giusto pensando tempo fa. Non ha molto senso dare priorità RT ad MPD e lasciare che la gestione dell'interfaccia audio (ALSA, USB, ecc) avvenga con scheduling e priorità normali...

Messaggio da **antonellocaroli** » 11 dic 2013, 19:15

UnixMan ha scritto:Devi realizzare uno script un po' più complesso. Per cominciare, è necessario identificare i diversi thread di mpd, ad es. così:
Codice: Seleziona tutto
$ ps -C mpd -Lfc
UID        PID  PPID   LWP NLWP CLS PRI STIME TTY          TIME CMD
mpd      30288     1 30288    5 TS   19 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30291    5 TS   19 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30293    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30294    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
mpd      30288     1 30295    5 RR   99 00:35 ?        00:00:00 /usr/bin/mpd /etc/mpd.conf
quindi puoi usare "chrt -p nn xxxxx" per impostare la priorità dei diversi thread.

BTW: sempre a proposito di RT, per caso ho visto questo: https://sites.google.com/site/computera ... ng-up-alsa

ci stavo giusto pensando tempo fa. Non ha molto senso dare priorità RT ad MPD e lasciare che la gestione dell'interfaccia audio (ALSA, USB, ecc) avvenga con scheduling e priorità normali...

Ciao Paolo,
il problema é che quando si da il restart a mpd quei PID cambiano...

Messaggio da **UnixMan** » 11 dic 2013, 19:23

antonellocaroli ha scritto:il problema é che quando si da il restart a mpd quei PID cambiano...

ovvio. Ma l'ordine di avvio dei diversi thread non dovrebbe cambiare...

hint: puoi usare "cut" (in un loop) oppure "awk", "perl", ecc per "estrarre" i pid che ti interessano e passarli a chrt.

Messaggio da **antonellocaroli** » 11 dic 2013, 19:47

UnixMan ha scritto:
antonellocaroli ha scritto:il problema é che quando si da il restart a mpd quei PID cambiano...
ovvio. Ma l'ordine di avvio dei diversi thread non dovrebbe cambiare...

hint: puoi usare "cut" (in un loop) oppure "awk", "perl", ecc per "estrarre" i pid che ti interessano e passarli a chrt.

paolo di linux so poco, molto poco...quello che hai scritto per me é quasi arabo

urge esempio pratico.

Messaggio da **Miclaud** » 14 dic 2013, 17:57

UnixMan ha scritto:
IMHO, è sbagliato: è il "buffer_before_play" che deve essere mooolto più basso, lasciando invece le dimensioni complessive del buffer sui valori consigliati. Per cominciare, io proverei a commentare quelle due righe in modo che vengano adottati i valori di default...

Avevi ragione. Impostando buffer_before_play con valori tra 1 e 5 (quindi percentuali minime) e commentando (quindi disattivando) la grandezza del buffer, la situazione è migliorata drasticamente! Ora ho problemi sono se faccio conversioni estreme, usando campionamenti che non sono multipli diretti.
Per dire:

44.1 -> 88.2 OK
44.1 -> 96 OK
44.1 -> 176.4 OK
44.1 -> 192 MALE
96 -> 192 OK
96 -> 176.4 MALE

Certo, il massimo sarebbe poter dire a MPD di usare campionature relativamente al file in input. Qualcosa come "raddoppia o quadruplica il file in input", in modo da poter usare sempre campionature multiple in potenza di due dei file in ingresso (che poi dovrebbe essere la pratica ottima da seguire, da quello che ho capito e che da informatico sarei portato a pensare).

Ora vedrò come giocare ulteriormente le impostazioni realtime (magari passando da FIFO a RR e giocando con le priorità).

Certo, con il VIA C7 tutto ciò non è necessario perché se la cava egregiamente con ogni conversione. Tuttavia ho notato come una motherboard Alix, con Geode LX800 consumi solo 0.40A/12V contro i ben 1.50A/12V del thinclient basato su VIA C7 Eden da 1Ghz. Chissà perché così tanta differenza. Non vorrei fosse la componente video a bruciare tanta energia...
Dal punto di vista sonico mi pare di notare un lieve vantaggio da parte di Alix, ma niente di eclatante, le metterei sullo stesso piano.

La mia prossima prova sarà con un thinclient Praim basato su Atom dual core N270. Vedremo come andrà

Messaggio da **Echo** » 18 dic 2013, 14:35

Ciao Michele, la faccenda è stabile o meglio aspettare se non si sa smanettare??

MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)

Re: MPD (Music Player Daemon)