upsampling (universo LMS/Squeezelite/Squeezeplay) | Stampa

Quote:

---

Originariamente inviato da marcoc1712

@DacPassion

Se vuoi che proviamo adesso ho tempo, ma se non ti va/non hai tempo faccio altro, dimmi tu.

---

Scusami ho visto solo ora che ero fuori a cena


Intanto per portare avanti le verifiche sulla differenza di impegno della cpu del render tra upsampling in locale e su LMS (visto che non riesco a fare upsampling in lms) ho fatto la prova tra un file 16/44 e uno 24/192 inviati da LMS (penso che in questo modo ho ricreato la stessa situazione per quel che riguarda il render)
Nei primi 30/40 secondi di ogni brano 24/192 il consumo di cpu nel render è più alto (arriva al 7-8% poi si assesta sul 2%) rispetto al 16/44 upsamplato a 192 in locale (non supero quasi mai il 2-3%). In quei 30/40 secondi se invece osservo l'uscita dei dati in rete del server si mantiene sui 12/14 MB/secondo poi si assesta sui 1,5/MB secondo. Quindi il render viene caricato di lavoro perché all'inizio di ogni brano riceve un flusso alto di dati.
Questi picchi di lavoro possono inficiare la qualità della riproduzione?

Quote:

---

Originariamente inviato da DacPassion

Scusami ho visto solo ora che ero fuori a cena


Intanto per portare avanti le verifiche sulla differenza di impegno della cpu del render tra upsampling in locale e su lms ho fatto la prova tra un file 16/44 e uno 24/192 inviati da lms (penso che in questo modo ho ricreato la stessa situazione per quel che riguarda il render)
La cosa strana è che nei primi 30/40 secondi di ogni brano 24/192 il consumo di cpu nel render è più alta (arriva al 7-8% poi si assesta sul 2%) rispetto al 16/44 upsamplato a 192 in locale (non supero quasi mai il 2-3%)

---

Nessun problema, sono uscito anch'io.

No, non è strana, o meglio, è in linea con quanto ha verificato Giovanni: Il file 24/192 è flac e Squeezelite deve convertirlo in PCM, mentre il 44.1/16 o è pcm, quindi non lo deve convertire, o è flac, ma viene convertito quando è ancora 44.1/16, quindi portato a 192/24.

Alla fine pare che la conversione fatta dopo l'upsampling sia molto più onerosa dell'upsampling stesso, da qui l'idea di fare SEMPRE la conversione prima, sia che l'usampling avvenga sul server che su squeezelite. Ovviamente partendo da file già in alta definizione non si può evitare, se non convertendo off line.

Analoghe conclusioni in merito all'utilizzo di banda, vedi i posts di Filippo.

Il carico iniziale è dovuto ai buffer impostati, diminuendoli calerà l'impegno iniziale ed aumenterà quello durante la riproduzione, v. miei post precedenti, si tratta di scegliere il male minore, nel caso ci sia effettivamente un male.

Francamente non sono più così convinto che l'upsampling sul server sia la strada da battere, vista la grande/enorme (a 384/32) differenza in termini di carico e di utilizzo di banda, se la contropartità è solo un qualche punto % di utilizzo di cpu in più sul renderer e comunque sempre sotto il 10%.

Ovviamente a meno che non verifichiate una differenza sostanziale in termini di qualità nei due modi.

Vediamo di farti andare l'upsampling così ci dai anche la tua opinione.

Di mio non riesco ad aiutarvi, non credo molto nei vantaggi dell'upsampling e di conseguenza non mi sono mai attrezzato con un dac che lo consenta, se non la scheda che uso per le misurazioni, che può si arrivare a 192, ma il confronto con l'AR e/o lo SB+ è improponibile.

Quote:

---

Originariamente inviato da DacPassion

Io ho la stessa configurazione della tua foto, il fatto che lmd mi scrive quella cosa riguardo il volume indica solo che lo legge nel tag o che lo sta facendo?

---

Bella domanda... Io non mi sono mai preoccupato xchè non il replay gain in nessun file. L'unica cosa che mi preoccupa è che ci sia qualcosa di sbagliato nella tua installazione, è sempre stato un problema l'upgrade su mac, comunque domani provo a convertire un file in flac aggiungo il replay gain, lo sposto su mac e vedo cosa succede da me.

Eventualmente puoi mettere il file da qualche parte ove io riesca a prelevarlo?

EDIT: Verificato creando un file nuovo con replay gain lo mostra anche se non lo applica.

Quote:

---

Originariamente inviato da marcoc1712

Nessun problema, sono uscito anch'io.

No, non è strana, o meglio, è in linea con quanto ha verificato Giovanni: Il file 24/192 è flac e Squeezelite deve convertirlo in PCM, mentre il 44.1/16 o è pcm, quindi non lo deve convertire, o è flac, ma viene convertito quando è ancora 44.1/16, quindi portato a 192/24.

Alla fine pare che la conversione fatta dopo l'upsampling sia molto più onerosa dell'upsampling stesso, da qui l'idea di fare SEMPRE la conversione prima, sia che l'usampling avvenga sul server che su squeezelite. Ovviamente partendo da file già in alta definizione non si può evitare, se non convertendo off line.

---

Il discorso non fa una piega però nel mio caso partendo da due file in LMS uno 16/44 uno 24/192 in entrambi i casi vengono trasformati in pcm da LMS prima di essere inviati. Al render quindi arrivano due file pcm: uno 24/192 e non viene processato, uno 16/44 che viene upsamplato.
Può essere che il carico di cpu nel render con il file 24/192 sia dato dal riempimento dei buffer?

@Giovanni e Antonello
Voi come tenete i buffer in squeezelite?

@Antonello
Per curiosità, tu che se non erro hai "i piedi in due staffe" hai mai verificato come si comporta lo NAA come consumi di cpu quando riceve file da hqplayer?

Quote:

---

Originariamente inviato da DacPassion

@Giovanni e Antonello
Voi come tenete i buffer in squeezelite?

@Antonello
Per curiosità, tu che se non erro hai "i piedi in due staffe" hai mai verificato come si comporta lo NAA come consumi di cpu quando riceve file da hqplayer?

---

;isterico;isterico;isterico non erri!!!

Dac il NAA con NAD consuma niente....dallo 0 allo 0,2% (i3 2100T)

Per i buffer adesso sto sperimentando buffer alti (160-320 mb) -b 163840-327680
lo standard di daphile é -b 3072:4096 (3-4 mb)

Io vado con 250mb stream e 500mb out

Curiosità, escludendo la faccenda upsampling, i compiti che esegue nad possono essere paragonati a quelli di squeezelite oppure sono diversi?

Quote:

---

Originariamente inviato da DacPassion

Il discorso non fa una piega però nel mio caso partendo da due file in LMS uno 16/44 uno 24/192 in entrambi i casi vengono trasformati in pcm da LMS prima di essere inviati. Al render quindi arrivano due file pcm: uno 24/192 e non viene processato, uno 16/44 che viene upsamplato.
Può essere che il carico di cpu nel render con il file 24/192 sia dato dal riempimento dei buffer?

---

Ah, giusto, nel tuo caso la conversione la fa sempre lms. Dipende dalle dimensioni di streaming buffer ed output buffer, certo, se le riduci anche il carico dovrebbe distribuirsi aggiormente. Non fa altro...

Per tutti e tre, se avete voglia di provare, potremmo 'misurare' il carico di cpu (lms e squeezelite) e di banda nelle seguenti condizioni e confrontarle:


a. flac -> flac

LMS: lettura Flac 44.1/16 + trasmissione Flac 44.1/16
SQUEEZELITE: ricezione Flac 44.1/16 + Conversione PCM 44.1/16 + play PCM 44.1/16


b. flac/pcm -> pcm

LMS: lettura Flac 44.1/16 + Conversione PCM + trasmissione PCM 44.1/16
SQUEEZELITE: ricezione PCM 44.1/16 + play PCM 44.1/16

c. flac/pcm/upsampling -> pcm

LMS: lettura Flac 44.1/16 + Conversione PCM + Upsampling 192/24 + trasmissione PCM 192/24
SQUEEZELITE: ricezione PCM 192/24 + play PCM 192/24

d. flac/pcm -> upsampling

LMS: lettura Flac 44.1/16 + Conversione PCM + trasmissione PCM 44.1/16
SQUEEEZELITE: ricezione PCM 44.1/16 + Upsampling 192/24 + play PCM 192/24

e. flac -> flac/pcm/upsampling

LMS: lettura Flac 44.1/16 + trasmissione Flac 44.1/16
SQUEEEZELITE: ricezione Flac 44.1/16 + Conversione PCM 44.1/16 + Upsampling 192/24 + play PCM 192/24

f. flac/upsampling -> flac/pcm

LMS: lettura Flac 44.1/16 + Upsampling 192/24 (*) + trasmissione Flac 192/24
SQUEEEZELITE: ricezione Flac 192/24 + Conversione PCM 192/24 + play PCM 192/24

g. flac/upsampling/pcm ->pcm

LMS: lettura Flac 44.1/16 + Upsampling 192/24+ Conversione PCM 192/24 + trasmissione PCM 192/24
SQUEEEZELITE: ricezione PCM 192/24 + play PCM 192/24

Questo ultimo caso, per quanto concerne rete e carico di squeezelite, equivale alla prova fatta da DacPassion partendo da un file già 192/24.

(*) = è probabile sia una decodifica, upsampling e ricodifica.

SE qualcuno è a conoscenza di tools che consentano di registrare il carico in modo continuo per singola operazione in tutti e tre gli ambienti (Mac,win e linux) sia per cpu che per rete, sarebbe ottimale.

Per me non c´é problema lo faccio volentieri a titolo di studio, visto che ho abbandonato l´idea di far fare resample a LMS, anche se secondo me ha qualcosina in piú a livello sonico, ma un po scomodo e non funziona con i file online (tipo Qbuz).

Ma partecipo volentieri...solo Marco se potresti aggiungere le varie stringhe da usare in LMS per il resample...in modo che sia uniforme per tutti..e che buffer usare in sqeezelite.

Quote:

---

Originariamente inviato da antonellocaroli

Per me non c´é problema lo faccio volentieri a titolo di studio, visto che ho abbandonato l´idea di far fare resample a LMS, anche se secondo me ha qualcosina in piú a livello sonico, ma un po scomodo e non funziona con i file online (tipo Qbuz).

Ma partecipo volentieri...solo Marco se potresti aggiungere le varie stringhe da usare in LMS per il resample...in modo che sia uniforme per tutti..e che buffer usare in sqeezelite.

---

OK, aggiungerò le stringhe per LMS direttamente nel testo. Per buffer di squeezelite intendi gli alsa buffer o stream/output? Per i primi usiamo i valori standard per il momento (100/3), per i secondi dipende essenzialmente dalla ram che uno ha, lascerei i valori standar usati da daphile, per esempio, (non ricordo quali sono, postali tu per favore).