Voyage Mpd e Kernel RT

[antonellocaroli]

Posto questa piccola guida (piú che altro come ho fatto io) per chi volesse provare Voyage mpd con Kernel RT.

Posto alcuni link che potrebbero essere utili:
http://guidainstallazionevoyagempdlinux.blogspot.co.at/
http://www.symphonic-net.com/kubotayo/a ... gempd.html
http://wiki.linuxaudio.org/wiki/start
http://linuxaudio.it/index.php/Latenza
http://soundex.ru/index.php?app=blog&mo ... &blogid=55
http://linuxaudio.it/index.php/Configur ... _GNU/Linux
https://sites.google.com/site/computera ... -for-audio
http://mubox.voyage.hk/realtime_kernel
http://www.audioasylum.com/cgi/vt.mpl?f ... o&m=109926

La guida é testata con Voyage mpd 0.9.1
iniziamo con lo scaricare il necessario:

apt-get install kernel-package fakeroot build-essential libncurses5-dev

cd /usr/src/

wget --no-check-certificate https://www.kernel.org/pub/linux/kernel ... 13.tar.bz2

wget http://mirror.voyage.hk/download/kernel ... yage_9.0-1

wget --no-check-certificate https://www.kernel.org/pub/linux/kernel ... .patch.bz2

tar xjvf linux-3.8.13.tar.bz2

cd linux-3.8.13

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

patch -p1 < <(bunzip2 -c ../patch-3.8.13-rt15.patch.bz2)

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

Editare i parametri:
Processor type and features -> Preemption Model -> Fully Preemptible Kernel (RT)
Select USB Audio/MIDI driver (refer to previous chater)

Potete configurare il kernel in base alle vostre esigenze
qualche indicazione qui: http://www.symphonic-net.com/kubotayo/a ... tml#config

Controllare che Timer frequency sia impostato a 1000 HZ

Ritornare al menu iniziale e selezionare>save an alternate configuration file>.conf

Exit

sed -rie 's/echo "\+"/#echo "\+"/' scripts/setlocalversion

make-kpkg clean

CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) fakeroot make-kpkg --initrd --revision=0 kernel_image kernel_headers

Installare i pacchetti appena creati:

dpkg -i ../linux-{headers,image}-3.8.13-rt15*.deb

update-grub

Non so perché ma bisogna editare sempre il menu.lst di grub
per cambiare le partizioni di avvio e quale kernel si vuole avviare di default.

Adesso bisogna Patchare MPD, altrimenti i parametri che si vanno a cambiare in mpd.conf non funzionano.
scaricare da qui http://www.voyage.hk/dists/experimental/mpd/ la versione che fa per voi

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

dpkg -i mpd_0.18.0git20130624-1_i386.deb

tutto qua.

mpd.conf

Codice: Seleziona tutto

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 "My Alsa"
device "hw:0,0"
priority "FIFO:52"
# format "44100:16:2" # optional
# mixer_device "default" # optional
# mixer_control "PCM" # optional
# mixer_index "0" # optional
}
audio_buffer_size               "51200"
buffer_before_play              "100%"

[Echo]

Hai avvertito differenze?

[sontero]

Hai avvertito differenze?

La domanda non è rivolta a me pero' io l'esperimento l'ho fatto e ne ho parlato nell'altro thread "VoyageMpd che ne pensate".
Ho sperimentato anche altre soluzioni : MpdPup , TinyCore+Deadbeef, Raspyfi 1.0 per Raspberry e naturalmente VoyageMPD versione normale.
per me VoyageMPD e MpdPup sostanzialmente ex aequo in testa. Ma dopo l'installazione e l'ascolto del kernel RT, Voyage ha preso decisamente il largo
in tutti i parametri . Io l'esperimento lo farei .

[antonellocaroli]

Hai avvertito differenze?

Ciao Echo,
attualmente non mi trovo in una posizione per avvertire finezze soniche...ma cosí con due casse di m.... posso dire che é il sistema che preferisco.
Ma se usi giá voyage puoi sempre provare...tanto non ci vuole molto a cambiare kernel all avvio...

[UnixMan]

mmh... per semplificare (notevolmente) le cose, si potrebbe anche provare ad usare un kernel RT precompilato:

http://packages.debian.org/search?keywo ... ection=all

Ad esempio:

http://packages.debian.org/wheezy-backp ... rt-686-pae

http://ftp.it.debian.org/debian/pool/ma ... 1_i386.deb

oppure anche:

http://packages.debian.org/jessie/linux ... rt-686-pae

http://ftp.it.debian.org/debian/pool/ma ... 1_i386.deb

[antonellocaroli]

mmh... per semplificare (notevolmente) le cose, si potrebbe anche provare ad usare un kernel RT precompilato:

Si é una soluzione sicuramente piú comoda.
ma io ho preferito compilare cosi da poter scegliere cosa mi serviva dal kernel

[UnixMan]

io ho preferito compilare cosi da poter scegliere cosa mi serviva dal kernel

è cosa buona e giusta...

[Miclaud]

Bravissimi che avete fatto questo esperimento! Speravo che qualcuno, con più competenze delle mie (pochissime) sul kernel realtime si avventurasse.

Scrivo poco qui ma vi seguo, ero presente anche al Bottom 2013, purtroppo il solo venerdì...

[Echo]

Bravissimi che avete fatto questo esperimento! Speravo che qualcuno, con più competenze delle mie (pochissime) sul kernel realtime si avventurasse.

Scrivo poco qui ma vi seguo, ero presente anche al Bottom 2013, purtroppo il solo venerdì...

Se provi sul tuo sistema fammi sapere

[Miclaud]

Allora, non è stato facile. Non sono un grande esperto di cross compilazione quindi, per semplificare le cose, ho preferito compilare tutto in loco nel voyage mpd che gira sulla mia alix1d. E' servito addirittura inserire una chiavetta usb formattata come linux-swap per sopperire alla scarsità di memoria RAM disponibile per la compilazione con make-kpkg.
Purtroppo se provavo a compilare dal mio pc fisso, con Ubuntu 12.04 64bit, anche usando l'opzione di make-kpkg --arch=i386 ottenevo un kernel non bootabile dalla alix, in quanto provvisto dell'opzione PAE non supportata dal processore Geode della macchina target. Inutile tentare di eliminare la voce dal menuconfig, la cosa risultava impossibile per qualche cavillo che sfugge alla mia esperienza, piuttosto ridotta al riguardo...

Detto ciò, ho messo su il kernel 3.8.13-rt e sembra funzionare correttamente. Ho poi installato mpd patchato per il realtime. Purtroppo se configuro il file mpd.conf con le opzioni rt suggerite, dopo qualche minuto di esecuzione (può essere mezz'ora come 30 secondi...) si pianta il demone mpd e su dmesg trovo questo errore:

Codice: Seleziona tutto

cannot submit urb (err = -18)

Sblocco il tutto solo riavviando tutta la macchina, non basta far ripartire il servizio mpd. Dipende sicuramente dalle opzioni rt nel file mpd.conf perché in questo istante sto usando senza problemi kernel rt e mpd patchato, senza opzioni definite in mpd.conf (quindi di fatto non sfruttando lo scheduler realtime).

Nel frattempo proverò anche a compilare il kernel più recente disponibile, il 3.10.17, così come proverò un .deb già disponibile sul sito di voyage, il 3.10.11-rt, magari è qualche bug legato alla 3.8.13-rt (che da qualche parte ho letto essere il più stabile, annamobbene ).

Sono ben accetti consigli, ovviamente. Alla fine della fiera vi fornirò i miei deb compilati, nel caso possano esservi di utilità.

[sontero]

Direi che dovresti usare il kernel 3.8.13-rt 15 come ha indicato antonellocaroli e non altri . Il kernel che usa Voyage 0.9.1 è il 3.8.13 .
Hai definito attentamente le opzioni di configurazione RT ?? Io ho eseguito tutte quelle che consiglia Kubotaio....con santa pazienza.
Perchè non posti il mpd.conf ? magari c'è qualche difetto nello script .

[UnixMan]

Per cominciare, io proverei ad usare un kernel precompilato, ad es. il 3.10 dai backports.

[Miclaud]

Prima di tutto grazie per l'aiuto.

Ho provato poco fa ad installare il kernel precompilato "3.10.11-voyage-rt-rt7".
Qui succede una cosa diversa. L'esecuzione del brano inizia con diversi drop, ben udibili, controllando con "top" vedo che la cpu è al 100%. Dopo una decina di secondi l'occupazione cala e si assesta sui consoni valori minimi e da lì non dà più problemi. Ai successivi cambi di traccia la cpu ritorna al 100% anche se stavolta i drop non sono udibili, per poi riassestarsi nuovamente al minimo.

Entrambe le prove ("3.8.13-rt15" e "3.10.11-voyage-rt-rt7") sono state fatte con le stesse impostazioni di mpd.conf che vi riporto di seguito

Codice: Seleziona tutto

music_directory                 "/media/music"
playlist_directory              "/media/music/mpd/playlists"
db_file                         "/media/music/mpd/tag_cache"
log_file                        "/var/log/mpd/mpd.log"
pid_file                        "/var/run/mpd/pid"
state_file                      "/var/lib/mpd/state"
sticker_file                   "/var/lib/mpd/sticker.sql"

user                            "mpd"

input {
        plugin "curl"
}

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"

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 "XMOS WaveIO"
        device "hw:0,0"
        priority "FIFO:52"
}

audio_buffer_size               "51200"
buffer_before_play              "100%"

Che ne pensate?

[UnixMan]

per caso il disco dove tieni la musica è formattato NTFS?

[Miclaud]

Uhm, no è in ext4. Posso sempre provare ad eseguire qualche brano copiato nella CF card del sistema...


Tra l'altro non mi è chiaro questo passaggio delle istruzioni al primo post:

Codice: Seleziona tutto

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

patch -p1 < <(bunzip2 -c ../patch-3.8.13-rt15.patch.bz2)

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

Perché copiamo un file di configurazione (tra l'altro della versione 2.6.38, quando sul sito voyage ce n'è uno della versione 3 del kernel) per poi sovrascriverlo con quello presente in /boot/, come accade nel comando dopo il patching ? Entrambi i file config vanno a finire in ./config, quindi di fatto verrebbe usato solo quello copiato per ultimo, alla generazione del menuconfig e nel successivo make, o mi sfugge qualcosa?

[sontero]

per caso il disco dove tieni la musica è formattato NTFS?

scusa Paolo se sono inopportuno. Che problema c'è ad avere il disco formattato NTFS ?
Il mio è così . Quindi ?...

[UnixMan]

Tra l'altro non mi è chiaro questo passaggio delle istruzioni al primo post:

neanche a me...

Perché copiamo un file di configurazione (tra l'altro della versione 2.6.38, quando sul sito voyage ce n'è uno della versione 3 del kernel) per poi sovrascriverlo con quello presente in /boot/, come accade nel comando dopo il patching ? Entrambi i file config vanno a finire in ./config, quindi di fatto verrebbe usato solo quello copiato per ultimo, alla generazione del menuconfig e nel successivo make, o mi sfugge qualcosa?

se la sequenza è quella, direi proprio di no... forse chi ha scritto la procedura ha fatto qualche revisione ma si è dimenticato qualche pezzo per strada?

scusa Paolo se sono inopportuno.

e perché mai?

Che problema c'è ad avere il disco formattato NTFS ?
Il mio è così . Quindi ?...

Il problema è che NTFS è assurdamente (quanto inutilmente) "pesante" e complicato (oltre a non essere documentato...). Sviluppare un "driver" per poterlo supportare su Linux è stata una impresa tutt'altro che facile. In effetti, sono stati sviluppati due driver: uno nativo, in kernel-space, ed un altro in user-space (via FUSE). Purtroppo, vuoi a causa di difficoltà tecniche vuoi a causa dello scarso interesse, il vero e proprio driver nativo (quello in kernel-space) è rimasto incompiuto (funziona in sola lettura). Da quando è stato sviluppato quello basato su FUSE, si usa quasi esclusivamente quello. Che funziona bene ma, essendo in user-space, ha un problema: è molto poco efficiente (non fosse altro che a causa dei numerosi "mode-switch" e "context-switch" che si rendono necessari). Per cui è sensibilmente più lento e consuma ancora più risorse di quanto non farebbe un driver nativo. In particolare, usa un mucchio di CPU (quando si accede al file system).

In breve, meglio evitare NTFS come la peste. Specie per l'uso in questione.

Per dischi rimovibili che devono essere accessibili da sistemi diversi, se appena possibile (cioè in sostanza se non si devono ospitare singoli file con dimensioni >=4GB) è meglio usare FAT32. Per tutto il resto è molto meglio usare file system nativi (ext2/3/4, btrfs, reiserfs, xfs, jfs, ecc).

[sontero]

Tra l'altro non mi è chiaro questo passaggio delle istruzioni al primo post:

neanche a me...

In questa guida dedicata all'audio viene indicata una procedura che mi pare sovrapponibile a quella indicata al primo post (che pure a me mi perplime), se c'è qualcosa di non corretto sarebbe opportuno portare chiarezza cosi si evita di fare le pecore e si corregge il tiro:
http://linuxaudio.it/index.php/Latenza# ... io_liquido

Perché copiamo un file di configurazione (tra l'altro della versione 2.6.38, quando sul sito voyage ce n'è uno della versione 3 del kernel) per poi sovrascriverlo con quello presente in /boot/, come accade nel comando dopo il patching ? Entrambi i file config vanno a finire in ./config, quindi di fatto verrebbe usato solo quello copiato per ultimo, alla generazione del menuconfig e nel successivo make, o mi sfugge qualcosa?

se la sequenza è quella, direi proprio di no... forse chi ha scritto la procedura ha fatto qualche revisione ma si è dimenticato qualche pezzo per strada?

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

scusa Paolo se sono inopportuno.
e perché mai?

Perchè non sono a casa mia. Chiedo e attendo una risposta . I principianti sono innanzitutto scocciatori : eccomi . Pertanto puoi anche ritenermi inopportuno, è
una tua facolta' ritenere il contrario.

Che problema c'è ad avere il disco formattato NTFS ?
Il mio è così . Quindi ?...

Il problema è che NTFS è assurdamente (quanto inutilmente) "pesante" e complicato (oltre a non essere documentato...). Sviluppare un "driver" per poterlo supportare su Linux è stata una impresa tutt'altro che facile. In effetti, sono stati sviluppati due driver: uno nativo, in kernel-space, ed un altro in user-space (via FUSE). Purtroppo, vuoi a causa di difficoltà tecniche vuoi a causa dello scarso interesse, il vero e proprio driver nativo (quello in kernel-space) è rimasto incompiuto (funziona in sola lettura). Da quando è stato sviluppato quello basato su FUSE, si usa quasi esclusivamente quello. Che funziona bene ma, essendo in user-space, ha un problema: è molto poco efficiente (non fosse altro che a causa dei numerosi "mode-switch" e "context-switch" che si rendono necessari). Per cui è sensibilmente più lento e consuma ancora più risorse di quanto non farebbe un driver nativo. In particolare, usa un mucchio di CPU (quando si accede al file system).

In breve, meglio evitare NTFS come la peste. Specie per l'uso in questione.

Per dischi rimovibili che devono essere accessibili da sistemi diversi, se appena possibile (cioè in sostanza se non si devono ospitare singoli file con dimensioni >=4GB) è meglio usare FAT32. Per tutto il resto è molto meglio usare file system nativi (ext2/3/4, btrfs, reiserfs, xfs, jfs, ecc).

Molto chiaro e circostanziato. Adesso finalmente con le tue parole ho messo a fuoco un annoso problema che avevo empiricamente riconosciuto . E' sicuramente
opportuno passare al filesystem FAT32 perchè il NTFS mi sta ammazzando la CPU. Dovro' decidermi e farlo.

[antonellocaroli]

Tra l'altro non mi è chiaro questo passaggio delle istruzioni al primo post:

neanche a me...

Ciao A tutti, premetto che di linux ne capisco poco,
io ho postato una procedura che con me ha funzionato, ne ho provate varie,
ho messo dei link in evidenza da dove ho preso spunto.
Se qualcuno ha da correggere errori ben venga.

[sontero]

Ciao A tutti, premetto che di linux ne capisco poco,
io ho postato una procedura che con me ha funzionato, ne ho provate varie,
ho messo dei link in evidenza da dove ho preso spunto.
Se qualcuno ha da correggere errori ben venga.

Io ne capisco anche meno ma di sicuro mi sono trovato bene anzi benissimo
seguendo la procedura indicata, anche se qualcosa non l'ho ben digerita. Ma
son qua per imparare...