www.audiofaidate.org

Stavo compilando il kernel 3.10.17 ma una mia cagata ha mandato a monte tutto... sto ricominciando da capo

Detto ciò, avevo preparato anche un altro server mpd per un amico, basato su una scheda con processore Via C7 il quale supporta, tra l'altro, sse, sse2 e, sopratutto, il PAE. Ho quindi potuto usare il kernel precompilato indicato più in alto in questo thread (la mia alix lo rifiutava), il 3.10-0.bpo.3-rt-686-pae

Ad orecchio è tutto perfetto ed è da un bel po' che gira senza problemi, tuttavia anche qui noto il problema della CPU al massimo all'inizio dell'esecuzione. Tuttavia, nessun drop di CPU. Chissà che le impostazioni rt non stressino la cpu? Il realtime per me è ancora un po' arabo, perdonate eventuali cagate che possa aver detto...

Miclaud ha scritto:tuttavia anche qui noto il problema della CPU al massimo all'inizio dell'esecuzione.

potrebbe essere legato al buffering. Come hai configurato questi due parametri?

audio_buffer_size <size in KiB>
buffer_before_play <0-100%>

Se hai configurato MPD per avere tenere un buffer relativamente ampio, ogni volta che cambia traccia mpd deve decodificare "di corsa" un bel pezzo del file per riempire il buffer. Su CPU (relativamente) lente, è abbastanza ovvio che il momentaneo picco di utilizzo della CPU sia evidente...

ref:
man mpd.conf
http://linux.die.net/man/5/mpd.conf

Ho usato i parametri consigliati:

Codice: Seleziona tutto

audio_buffer_size               "51200"
buffer_before_play              "100%"

Il fatto è che non ricordo di aver mai avuto problemi con kernel non rt, usando questi parametri. Magari provo a fare delle prove dimensionando il buffer.
Forse l'audio skippa con l'rt proprio perché il processo che si occupa di riempire il buffer, avendo minor priorità, non riesce a star dietro al decodificatore. Però è strano perché quest'ultimo dovrebbe partire solo quando il buffer è pieno al 100%, quindi con un buon margine di sicurezza alle spalle... magari provo ad ingrandire un po' il buffer.

sontero ha scritto:Paolo fai chiarezza anche su questo punto . C'è qualche errore di procedura e quale ?

di sicuro c'è quello che hai indicato proprio tu...

Questo comando:

Codice: Seleziona tutto

cp ../config-2.6.38-voyage_9.0-1 ./.config

prende la configurazione di un vecchio kernel Voyage e la copia per utilizzarla come "base" per la configurazione di quello nuovo ma, quello successivo:

Codice: Seleziona tutto

cp /boot/config-$(uname -r) .config

sovrascrive la vecchia configurazione con quella del kernel attualmente in esecuzione. Per cui evidentemente ciò rende del tutto inutile scaricare la vecchia config e copiarla.

Probabilmente si tratta di una svista: in precedenza utilizzava quella vecchia config come base (forse all'epoca era proprio quella la versione del kernel che utilizzava...), mentre in seguito ha pensato di utilizzare invece quella del kernel corrente. Ha aggiunto alla procedura il comando relativo ( cp /boot/config-$(uname -r) .config ), ma si è dimenticato di eliminare i riferimenti al vecchio metodo.

N.B.: usare la configurazione del kernel attualmente in esecuzione ( /boot/config-$(uname -r) ) può essere una buona idea se e soltanto se si sta compilando il nuovo kernel direttamente sulla macchina dove girerà quello nuovo!

In caso contrario, meglio copiare la configurazione di un kernel Voyage (di una versione più "vicina" possibile a quella che si sta compilando, ma non più nuova di questa) e come base utilizzare quella.

In particolare, questo (usare come base la config di un kernel Voyage, avendo cura di non sovrascriverla con quella del kernel locale...) è quello che si deve fare se si vuole compilare il nuovo kernel su una macchina diversa da quella su cui dovrà girare (cosa che conviene decisamente fare, se si dispone di una macchina sensibilmente più performante di quella).

Per evitare di fare confusione, IMO conviene separare questi due comandi:

Codice: Seleziona tutto

cp /boot/config-$(uname -r) .config && make menuconfig

nei suoi due costituenti:

Codice: Seleziona tutto

cp /boot/config-$(uname -r) .config

e

Codice: Seleziona tutto

make menuconfig

(l'operatore "&&" è l'operatore "AND" logico: esegue il comando alla sua destra solo se quello alla sua sinistra è stato eseguito senza errori).

Come detto, il primo (la copia della configurazione del kernel in esecuzione sulla macchina locale) va eseguito solo se si sta compilando direttamente sulla macchina Voyage. In caso contrario al suo posto si deve copiare la configurazione di un opportuno kernel Voyage (adatto alla macchina dove dovrà girare il nuovo kernel).

Miclaud ha scritto:Forse l'audio skippa con l'rt proprio perché il processo che si occupa di riempire il buffer, avendo minor priorità, non riesce a star dietro al decodificatore.

possibile che sia qualcosa del genere... ma, più che quelli (che sono tutti "figli" di MPD, quindi verosimilmente hanno tutti priorità adeguate), è probabile che sia invece il "driver" della scheda audio (o quello USB, ecc) che hanno priorità insufficienti e non riescono a fare correttamente il loro lavoro...

Miclaud ha scritto:magari provo ad ingrandire un po' il buffer.

au contraire.

Se la causa è quella ipotizzata, così facendo peggioreresti solo il problema. Piuttosto per prima cosa io proverei a rimettere entrambi quei parametri ai loro valori di default. Poi al limite puoi provare ad ingrandire un po' il buffer, ma lasciando il "preload" sempre al 10% (default) o giù di li.

IMHO esagerare con il buffering (specie se non è necessario) può essere controproducente.

UnixMan ha scritto: Questo comando:
Codice: Seleziona tutto
cp ../config-2.6.38-voyage_9.0-1 ./.config
prende la configurazione di un vecchio kernel Voyage e la copia per utilizzarla come "base" per la configurazione di quello nuovo ma, quello successivo:
Codice: Seleziona tutto
cp /boot/config-$(uname -r) .config 
sovrascrive la vecchia configurazione con quella del kernel attualmente in esecuzione. Per cui evidentemente è del tutto inutile scaricare la vecchia config e copiarla.

Probabilmente si tratta di una svista: in precedenza utilizzava quella vecchia config come base (forse all'epoca era proprio quella la versione del kernel che utilizzava...), mentre in seguito ha pensato di utilizzare quella del kernel corrente. Ha aggiunto il comando relativo, ma si è dimenticato di eliminare dalla procedura i riferimenti al vecchio metodo.[/i]

Grazie del chiarimento esaustivo. Era un punto che francamente mi destava dubbi di opportunita' e la tua precisazione è sicuramente utile per il futuro. In ogni caso la cosa ha funzionato anche se con qualche ridondanza.
nel caso non avessi letto ho espresso cosa penso dell'innovazione "libsoxr" nell'altro thread da te aperto su MPD

X Miclaud
visto che hai messo su il kernel RT perche' non provi anche "libsoxr0"( la libreria alternativa a libsamplerate) che è un bel passo in avanti in termini di prestazioni audio.
http://www.audiofaidate.org/forum/viewt ... 7&start=40 (thread aperto da Unixman)

in voyage experimental è disponibile (da un bel pezzo, ma l'ho visto solo ora...) un kernel 3.10 RT:

http://www.voyage.hk/dists/experimental ... 1_i386.deb

direi di provarlo.

potete anche aggiungere al vostro sources.list l'ultima riga qui sotto:

Codice: Seleziona tutto

#deb http://www.voyage.hk/dists/0.9 ./
deb http://www.voyage.hk/dists/unstable ./
deb http://www.voyage.hk/dists/experimental ./

ed installarlo con apt (idem per la versione "rt-enabled" di mpd).

Ciao Paolo,
aggiungendo quelle righe dopo apt-get update mi da questo messaggio:

Codice: Seleziona tutto

Reading package lists... Done
W: Duplicate sources.list entry http://www.voyage.hk/dists/experimental/ ./ Packages (/var/lib/apt/lists/www.voyage.hk_dists_experimental_._Packages)
W: You may want to run apt-get update to correct these problems

antonellocaroli ha scritto:W: Duplicate sources.list entry http://www.voyage.hk/dists/experimental/

...evidentemente, avevi già una riga uguale!

(quindi devi togliere quella duplicata)

UnixMan ha scritto:
antonellocaroli ha scritto:W: Duplicate sources.list entry http://www.voyage.hk/dists/experimental/
...evidentemente, avevi già una riga uguale!

(quindi devi togliere quella duplicata)

mhh non mi sembra...

questo il sources.list:

Codice: Seleziona tutto

deb http://ftp.jp.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.jp.debian.org/debian/ wheezy main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

# Primary Debian Mirror Sites (http://www.debian.org/mirror/list)

#deb http://www.voyage.hk/dists/0.9 ./
deb http://www.voyage.hk/dists/unstable ./
deb http://www.voyage.hk/dists/experimental ./

UnixMan ha scritto:in voyage experimental è disponibile (da un bel pezzo, ma l'ho visto solo ora...) un kernel 3.10 RT:

http://www.voyage.hk/dists/experimental ... 1_i386.deb

direi di provarlo.

Si, lo avevo accennato (in verità non molto chiaramente) qualche post fa. Al momento nel mio sistema girano: 3.8.13 standard e le versioni rt di 3.8.13, 3.10.11 e 3.10.17 (sono riuscito a compilarlo).

Al momento con l'ultima mi sto trovando bene. I picchi di CPU ci sono ancora, anche impostando il buffer di default. Quasi quasi provo a scollegare il mio hard disk usb esterno e fare delle prove con dei file audio copiati nella CF card. Chissà che non ci sia qualche insidia nel fatto che uso una Xmos usb... tutti questi componenti usb che si contendono il bus, magari rilevo qualche dato interessante.

Se riesco a fare la cross-compilazione vi rendo disponibile il deb della 3.10.17. Quello che uso ora supporta solo il Geode LX della mia Alix (ho voluto fare lo sborone) ma ne vorrei realizzare uno X86 generico. Ora provo come hai suggerito tu, UnixMan, copiandomi sull'AMD X4 (ben altra bestia) il file config, usando poi il flag --arch=i386. Speriamo sia sufficiente.

Vi aggiornerò in caso di ulteriori risultati. Poi seguiranno i "test drive" nel mio impianto e in quello di un amico con la mia stessa sorgente

sontero ha scritto:X Miclaud
visto che hai messo su il kernel RT perche' non provi anche "libsoxr0"( la libreria alternativa a libsamplerate) che è un bel passo in avanti in termini di prestazioni audio.
http://www.audiofaidate.org/forum/viewt ... 7&start=40 (thread aperto da Unixman)

Uhm... purtroppo Sox lo provai tempo fa. Il mio Geode non può davvero farcela. Con il VIA C7 da 1Ghz del mio amico invece riesco ad usarlo, ma solo max 96Khz... chissà se grazie al clock più alto o magari al supporto per sse e sse2 (sempre che SOX utilizzi quelle istruzioni). Se salgo ancora con la frequenza di campionamente il suono incespica inevitabilmente.

Ahhh, i bei tempi di quando usavo un I3-2100T Sandy Bridge. Anche con downclock e downvolting (mi pare andasse a 900Mhz

) macinava sia Sox che Libsamplerate (ancor più pesante del primo) con una facilità disarmante...

antonellocaroli ha scritto: mhh non mi sembra...

questo il sources.list:

prova a vedere se ci sono files aggiuntivi dentro /etc/apt/sources.list.d/ e verificane il contenuto... (tutto ciò che nei files dentro quella dir è come se fosse scritto direttamente nel sources.list).

Miclaud ha scritto:Uhm... purtroppo Sox lo provai tempo fa. Il mio Geode non può davvero farcela.

forse no, ma fai presto a fare una prova... tentar non nuoce. La libsoxr è decisamente efficiente. Adesso esci con lo stream così com'è ("bit-perfect") o fai comunque resampling? se fai resampling, cosa usi?

Miclaud ha scritto:Ora provo come hai suggerito tu, UnixMan, copiandomi sull'AMD X4 (ben altra bestia) il file config, usando poi il flag --arch=i386. Speriamo sia sufficiente.

se non ricordo male, non devi fare nulla (anzi, potrebbe creare problemi). L'architettura di destinazione è scritta nel .config, il sistema di build dovrebbe pensare automaticamente a tutto il resto. Magari, se fai il build su una architettura amd64, assicurati di avere installato il supporto "multilib"...

UnixMan ha scritto: forse no, ma fai presto a fare una prova... tentar non nuoce. La libsoxr è decisamente efficiente. Adesso esci con lo stream così com'è ("bit-perfect") o fai comunque resampling? se fai resampling, cosa usi?

Aspetta, ma facendo una breve ricerca scopro che libsoxr è una cosa diversa da libsox. Vedo che la prima è pensata per un uso realtime, meno complessa e quindi meno onerosa per la CPU, sbaglio?
Sarà il caso di provarla allora, solo che non la trovo nei repository, mi sa che devo abilitare qualcos'altro, ora mi ingegno un po' e vi faccio sapere com'è andata.

Comunque al momento attuale vado in "bit-perfect". Sia con sox che libsamplerate era impossibile qualunque tipo di upsampling: CPU al massimo, drop continui e difficoltà nel fermare il processo audio, per quanto intasato.

UnixMan ha scritto: se non ricordo male, non devi fare nulla (anzi, potrebbe creare problemi). L'architettura di destinazione è scritta nel .config, il sistema di build dovrebbe pensare automaticamente a tutto il resto. Magari, se fai il build su una architettura amd64, assicurati di avere installato il supporto "multilib"...

Uhm, ho provato al volo poco fa ma ho un imprevisto. Dopo aver lanciato il comando make-kpkg l'utility comincia a chiedermi di scegliere tra varie opzioni, come se non avesse info sufficienti dal file .config... mah, riproverò in caso! Sennò mi armo di pazienza e compilo tutto dal Geode, povero lui

Miclaud ha scritto:Aspetta, ma facendo una breve ricerca scopro che libsoxr è una cosa diversa da libsox. Vedo che la prima è pensata per un uso realtime, meno complessa e quindi meno onerosa per la CPU, sbaglio?

non sbagli. È basata sul codice di sox, ma non è esattamente la stessa cosa.

Miclaud ha scritto:Sarà il caso di provarla allora, solo che non la trovo nei repository, mi sa che devo abilitare qualcos'altro, ora mi ingegno un po' e vi faccio sapere com'è andata.

leggi il topic su MPD, ci sono tutti i dettagli.

Miclaud ha scritto:Uhm, ho provato al volo poco fa ma ho un imprevisto. Dopo aver lanciato il comando make-kpkg l'utility comincia a chiedermi di scegliere tra varie opzioni, come se non avesse info sufficienti dal file .config...

se il file .config proviene da una versione diversa del kernel è normale: ti dovrebbe chiedere di configurare tutte (e sole) le opzioni che sono nuove e/o diverse. Se hai interrotto, per sicurezza ti conviene ricopiare il .config e dare il comando:

Codice: Seleziona tutto

make oldconfig

prima di lanciare di nuovo make-kpkg.

Grazie mille, sto facendo tutte le prove del caso. Ti saprò dire

Miclaud dai un'occhiata qua forse potrebbe esserti utile per i tuoi problemi ( Disturbi di interrupt ) :
http://wiki.ubuntu-it.org/Hardware/Audi ... blemiAudio

Paolo sicuramente hai una soluzione a questo:
quando avvio voyage in single user ad un certo punto si ferma l´avvio con un messaggio tipo:

Codice: Seleziona tutto

Give root password for maintenance (or type Control-D to continue)

Premo control-d e continua

é possibile eliminare questo avviso? un po fastidioso.

antonellocaroli ha scritto:Paolo sicuramente hai una soluzione a questo:
quando avvio voyage in single user ad un certo punto si ferma l´avvio con un messaggio tipo:

scusa, ma se vuoi un avvio normale perché mai prima chiedi il single-user mode? quella è una modalità speciale, che si limita a montare i file system ed avviare direttamente una shell sulla prima console. Serve solo per fare alcune operazioni molto particolari (di solito per "riparare" un sistema che ha problemi), non per l'uso normale!

Tra l'altro, se a quel prompt non dai la password di root (ma premi Ctrl-d) il sistema procede con il boot normale, come se non avessi richiesto il single-user mode. Se vuoi andare in single-user devi dare la password di root; in caso contrario devi semplicemente selezionare l'avvio normale da GRUB e (salvo problemi) il sistema si avvia normalmente senza chiedere nulla.

www.audiofaidate.org

Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT

Re: Voyage Mpd e Kernel RT