Gentoo + Squeezelite-R2

[bigtube]

@bibo
Ho testato HQPlayer su Gentoo e ho gia' detto che mi è piaciuto
Fra i sttaggi che mi hai consigliato di provare quello che mi ha convinto
di piu' è stato a parita' di altri "poli-sinc-mp" e "Dither NS5" con resampling a 384K e "DAC bits=24" (adatto ai 1704)

[marcoc1712]

opinione legittima. Sta di fatto che il sottoscritto per es. non tornera' indietro....ci ho provato...ma di volata son tornato a Gentoo.
Inoltre lo sbattimento per essere completo deve prevedere l'installazione anche del server con LMS+C3PO su Gentoo....proprio oggi
ho provato a tornare sul vecchio server con Debian....l'ho lasciato immediatamente senza il minimo dubbio.
Anche senza orgasmo siamo su un altro livello a sistema completo. Di "apparizioni mariane" nessuno ha parlato
Sappiamo tutti che per piccoli o meno piccoli miglioramenti bisogna "spendere" tanto. E di certo non eravamo a "piedi" prima.
Nessuno ha detto che era facile.....inoltre hai fatto attenzione alla compilazione del Kernel....anche quello è un passo fondamentale
Negli screenshot riportati nella guida ci sono i passaggi minimi per un kernel gia' ben organizzato per partire....poi si puo' fare di meglio.
Se la pazienza è poca o anche il tempo è risicato c'è una marea di sistemi operativi a disposizione.
C'è anche chi ascolta con le cineserie e si dichiara soddisfatto. Il mondo è bello perchè vario anche se noi lo vogliamo assoggettare a tutti i costi.

Mi prendo il mio tempo per formarmi una opinione e anche per giocare con i parametri, adesso sono ancora quelli per Debian.

Qualcosa di diverso c'è, o almeno mi pare, anche se l'impostazione generale, per le mie orecchie e per il mio impanto, non è molto dissimile. Passare OsX o win cambia a mio avviso di più (senza indicazioni di merito), come di più può cambiare il cavo USB.

se ho fatto attenzione? ...ho seguito la guida ed impostato in modo solo leggermente diverso le cose che mi sembravano più evidenti, in primisi i CFLAGS. Le ottimizzazioni eventualmente in un secondo momento, adesso - anche sapendo dove mettere le mani - non sarei in grado di distinguere il risultato nemmeno potessi conforntarlo all'istante, dopo 6 ore di attesa per me è impossibile.

Digerisco il risulatato e poi vediamo. Sono fatto così.

Se parliamo di ottimizzazione 'tecnica' dell'installato, mi pare evidente che ci sarebbero grandi possibilità.

La pirma sarebbe di compilare tutti i pacchetti in binario e confezionare un sistema 'clone' ma senza sorgenti, senza layman e con solo il minimo per fare l'installazione dai pacchetti precompilati. Certamente sarebbe molto più leggero, in termini di spazio e forse anche di boot, ma io credo che quello sia sostanzialmente ininfluente, ai nostri fini, a meno di non avere HD realmente piccoli, con 64 GB non ci sono problemi.

Con il bufferone non pagina mai, quindi da questo punto di vista problemi non ce ne sono, un paio di processi IRQ (credo la rete e USB) 'bevono' molto più CPU che non in debian, ma siamo comunque sotto il 5% di utilizzo.

[bibo01]

@bibo
Ho testato HQPlayer su Gentoo e ho gia' detto che mi è piaciuto
Fra i sttaggi che mi hai consigliato di provare quello che mi ha convinto
di piu' è stato a parita' di altri "poli-sinc-mp" e "Dither NS5" con resampling a 384K e "DAC bits=24" (adatto ai 1704)

Continuerai ad usarlo?

Io, invece, mi sono arenato sulla necessità di avere una chiavetta da 32GB che non possiedo ...per il momento.

[bigtube]

Continuerai ad usarlo?

Io, invece, mi sono arenato sulla necessità di avere una chiavetta da 32GB che non possiedo ...per il momento.

Guarda....sono sincero...merita...ma dal momento che sono pienamente soddisfatto dal mio sistema abituale con lms e squeezelite-R2 e la mia convinta fede open source oltre al fatto che a me non interessa il dsd....dovro accontentarmi del periodo di prova.
Sicuramente e' un player di eccellenza.

[marcoc1712]

questa credo dovrebbe andare bene

# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

EAPI=6

inherit eutils user flag-o-matic git-r3

DESCRIPTION="Small headless Squeezebox emulator. R2 version is designed to play server side decoded and oversampled pcm streams. "
HOMEPAGE="https://github.com/marcoc1712/squeezelite-R2"
SRC_URI="https://github.com/marcoc1712/${PN}/archive/v${PV}-(R2).tar.gz -> ${P}.tar.gz"

LICENSE="GPL-3"
SLOT="0"
KEYWORDS="amd64 ~x86"
IUSE="dsd resample visexport ffmpeg lirc"

DEPEND="media-libs/alsa-lib
        media-libs/flac
        media-libs/libvorbis
        media-libs/libmad
        media-libs/faad2
        media-sound/mpg123
        resample? ( media-libs/soxr )
        visexport? ( media-sound/jivelite )
        ffmpeg? ( media-video/ffmpeg )
        lirc? ( app-misc/lirc )
"
RDEPEND="${DEPEND}
         media-sound/alsa-utils"

pkg_setup() {
    # Create the user and group if not already present
    enewgroup squeezelite
    enewuser squeezelite -1 -1 "/dev/null" audio
}

src_unpack() {
    mkdir ${S}
    tar -xzvf ${DISTDIR}/${P}.tar.gz -C ${S} --strip-components=1 &> /dev/null || die "unpack failed"    
}

src_prepare () {
    # Apply patches
    epatch "${FILESDIR}/${P}-gentoo-makefile.patch"
    eapply_user
}

src_compile() {
    if use dsd; then
        append-cflags "-DDSD"
        einfo "dsd support enabled via dsd2pcm"
    fi

    if use ffmpeg; then
        append-cflags "-DFFMPEG"
        einfo "alac and wma support enabled via ffmpeg"
    fi

    if use resample; then
        append-cflags "-DRESAMPLE"
        einfo "resample support enabled via soxr"
    fi

    if use visexport; then
        append-cflags "-DVISEXPORT"
        einfo "audio data export to jivelite support enabled"
    fi
    
    if use lirc; then
        append-cflags "-DIR"
        einfo "infra-red support enabled via lirc"
    fi
    
    # Build it
    emake || die "emake failed"
}

src_install() {
    dobin squeezelite-R2
    dodoc LICENSE.txt

    newconfd "${FILESDIR}/${PN}.conf.d" "${PN}"
    newinitd "${FILESDIR}/${PN}.init.d" "${PN}"
}

pkg_postinst() {
    # Provide some post-installation tips.
    elog "If you want start Squeezelite automatically on system boot:"
    elog "  rc-update add squeezelite-R2 default"
    elog "Edit /etc/conf.d/squeezelite-R2 to customise -- in particular"
    elog "you may want to set the audio device to be used."
}

Correggo quanto scritto in precedenza.

Questo ebuild va bene per com'è, al netto di voler prima o poi correggere le dipendenze di compilazione esviluppo (DEPEND e RDEPEND), ma bsognerebbe indagare. Quello che, erroneamente, pensavo sufficiente fare nelle IUSE, bisogna in realtà farlo in:

/etc/portage/package.use/squeezelite-R2

inserendo la riga, es.:

media-sound/squeezelite-R2 -dsd -ffmpeg -lirc -resample -visexport

assumendo che media-sound sia la category assegnata nel vs. overlay a squeezelite.

in questo modo vengono valorizzate opportunamnete le USE FLAGS locali al pacchetto squeezelite-R2, sovrascrivendo quelle globali, se dichiarate.

Pensavo fosse sufficiente la IUSE, ma mi sbagliavo, lì viene solo dichiarata, non valorizzata, indipendentemente dai modificatori aggiunti.

Risolto questo aspetto, non c'è motivo per mantenere un ebuild separato, quindi prego tutti di far rferimento a quello che rilascerà Filippo ed a tale proposito aggiungo che quetso THD si può anche chiudere, continuando ev. di la per ulteriori approfondimenti/supporto/chiarimenti...

NOTA SULLE USE FLAG LOCALI:

In fase di emerge portage calcola le dipendenze e le use flags del pacchetto, queste ultime vengono risolte su una 'gerarchia' che comprende, tra gli altri livelli, le USE FLAGS locali e le globali.

Le prime sono definite in /etc/portage/package.use/ le seconde in /etc/portage/make.conf

Come consigliato dal manuale, nelle USE FLAG generali bisognerebbe mettere SOLO quelle 'ufficiali' e solo se usate in modo congruo da più (almeno 5) pacchetti diversi, quelle non ufficiali e le eccezioni vanno gestite localmente per pacchetto.

es. sarebbe un errore mettere dsd o resample o visexport, nelle USE FLAGS globali, dato che non sono censite tra le opzioni ufficiali ma sono tipiche solo di Squeezelite (con quel significato).

Se, ad esempio, MPD deve usare ffmpeg e squeezelite no, è sbagliato (e scomodo, dovendo ricordarsi di modificarle prima di ogni compilazione) mettere -ffmpeg o ffmpeg nelle USE FLAGS glogali, mentre è corretto metterlo in quelle locali di entrambi i pacchetti.

Se si hanno più players installati e tutti i usano ffmpeg tranne squeezelite, allora può essere conveniente 'promuovere' la USE FLAGS ffmpeg a livello generale, mantenendo la negazione a livello locale SOLO per suqeezelite.

In questo modo si gestiscono bene i 'conflitti' tra use flags , mantenenedo il sitema sempre pronto ed allineato per una compilazione, senza preoccuparsi di dover variare manualmente le use flags globali.

Rinunciare a questa opzinea mio avviso compromette uno dei principali valori di gentoo, che è proprio nella capacità di orchestrare le dipendenze tra pacchetti in funzione delle scellte dell'utente, applicazione per applicaziione, non solo e non tanto a livellio di sistema in generale.

Spero sia utile.

[antonellocaroli]

media-sound/squeezelite-R2 -dsd -ffmpeg -lirc -resample -visexport
.

Basta dare

USE="-dsd -ffmpeg -lirc -resample -visexport" emerge --ask squeezelite-R2

opp

USE="dsd -ffmpeg -lirc -resample -visexport" emerge --ask squeezelite-R2

opp

USE="dsd -ffmpeg -lirc resample -visexport" emerge --ask squeezelite-R2

ecc

Opp commentare la la Riga alle use nel make.conf

ma se non sbaglio a quel punto dará un errore per le dipendenze obbligate...

a meno che non dai

USE="flac mpg123 ..." emerge --ask squeezelite-R2

[marcoc1712]

Basta dare

USE="-dsd -ffmpeg -lirc -resample -visexport" emerge --ask squeezelite-R2

opp

USE="dsd -ffmpeg -lirc -resample -visexport" emerge --ask squeezelite-R2

opp

USE="dsd -ffmpeg -lirc resample -visexport" emerge --ask squeezelite-R2

ecc

In quetso modo stai usando variabili locali che perdi alla chiusura della sessione, sono l'ultimo dei livelli di gerarchia, da usare per sovrascrivere le USE locali per quella specifica run di emerge.

NON è lo striumento giusto, dato che devi intervenire manualmente volta per volta e ricordartelo,in caso di compilazione globale, non riesci.

Opp commentare la la Riga alle use nel make.conf

ma se non sbaglio a quel punto dará un errore per le dipendenze obbligate...

a meno che non dai

USE="flac mpg123 ..." emerge --ask squeezelite-R2

A parte che in make.conf dovresti mettere solo le USE FLGAS censite (v. qui https://www.gentoo.org/support/use-flags/), non è comunque un buon metodo, dato che devi ricordarti di modificarle ogni qual volta compili un pacchetto diverso ed in caso di compilazione globale, non riesci.

Anche in gento c'è spazio per l'individualismo anarchico delle applicazioni, non solo per il centralismo cooperativo del sistema, per richiamare la divertentissima esposizione di Paolo...

Puoi comunque fare come vuoi, sono solo strumenti tra i quali puoi scegliere quello che più ti piace, l'importante però è sapere che ESISTONO due livelli di USE FLAGS: Globali e Locali e ci sono delle regole che definiscono quando è gusto usare le une o le altre. Puoi anche decidere di usarne solo uno per scekta ideologica, ma...

[antonellocaroli]

In quetso modo stai usando variabili locali che perdi alla chiusura della sessione, sono l'ultimo dei livelli di gerarchia, da usare per sovrascrivere le USE locali per quella specifica run di emerge.

NON è lo striumento giusto, dato che devi intervenire manualmente volta per volta e ricordartelo,in caso di compilazione globale, non riesci.



A parte che in make.conf dovresti mettere solo le USE FLGAS censite (v. qui https://www.gentoo.org/support/use-flags/), non è comunque un buon metodo, dato che devi ricordarti di modificarle ogni qual volta compili un pacchetto diverso ed in caso di compilazione globale, non riesci.

Anche in gento c'è spazio per l'individualismo anarchico delle applicazioni, non solo per il centralismo cooperativo del sistema, per richiamare la divertentissima esposizione di Paolo...

Puoi comunque fare come vuoi, sono solo strumenti tra i quali puoi scegliere quello che più ti piace, l'importante però è sapere che ESISTONO due livelli di USE FLAGS: Globali e Locali e ci sono delle regole che definiscono quando è gusto usare le une o le altre. Puoi anche decidere di usarne solo uno per scekta ideologica, ma...

Per questo suggerisco sempre --ask , e ho sempre (o quasi) detto togliete quello che non vi interessa....
bisogna stare attenti a quello che succede....

il caso di squeezelite é troppo semplice.

ma se esce fuori qualcosa che vada bene in generale...ben venga

[UnixMan]

BTW: lo correggiamo il titolo del topic? “Gento” con una 'o' sola nun se po' vede'...

[marcoc1712]

Per questo suggerisco sempre --ask , e ho sempre (o quasi) detto togliete quello che non vi interessa....
bisogna stare attenti a quello che succede....

il caso di squeezelite é troppo semplice.

ma se esce fuori qualcosa che vada bene in generale...ben venga

Scusa, ma non capisco le obiezioni.

Non si tratta di togliere o mettere quello che interessa o non interessa qui o la, si tratta di usare gli strumenti giusti per ottenere il risultato voluto.

Prima si definisce quello che si vuole ottenere, quindi si disegna la soluzione usando i migliori strumenti diponibili, non il contrario.

In che senso il caso di squeezelite è 'troppo semplice'?

Vuoi dire che casi più complessi non possono essere gestiti con una combinazione opportuna di USE FLAGS globali e locali?

Io credo di no, anzi, più le stuazioni sono complesse, più è preziosa la possibilità di poterle gestire individualmente, più separi MENO devi 'stare attento' a quello che succede runtime, al prezzo di porre maggiore attenzione in fase progettuale.

Concetto di separazione degli ambiti (o dei problemi).

Comunque, LAYMAN è sufficentemente complesso? Se no, mi porti un esempio ove non è possibil usarle? Giusto per capire a cosa ti riferisci.

Certo che va bene in generale, non è un modo che mi sono inventato io, è come funzionano le USE FLAGS in portage...

Dovrebbe ormai esserti chiaro che l'affermazione:

gentoo/portage ragiona sul sistema no sul singolo software...

semplicemente - e fortunatamente - non è vera, la accantoniamo?