note libere

la casa di c-3PO e squeezelite-R2

Tag: Squeezelite

Quale hardware per squeezelite-R2?

Molti lo chiedono e la risposta è nello stesso tempo semplicissima e complicata.

In breve: Qualsiaisi. Da SOC minimalisti come il Rasperry PI, AlixBoard (ottima), Beagle Bone Black, Cubox, ai thin Client anche vecchiotti, fino ai più moderni sistemi Intel o AMD o ai mac d’antan, squeezebox e persino qualche modello di router. La lista è limitata solo dalla capacità dell’hw di eseguire uno dei sistemi operativi supportati (di certo mac OSx dalla 10.5 in su, WIndiws XP o superiori, Linux vari), ma anche molto altro, semplicemente compilando il sorgente per la piattaforma desiderata.

Ma non su tutte le piattaforme si ottengono gli stessi risultati in ogni circostanza.

Se si usa squeezelite come ‘puro’ player, come consigliato su queste pagine,  è molto probable che qualsiasi hw supportato non dia problemi particolari, visto il bassissimko utilizzo di risorse, ma bisogna considerare che su sistemi non unix utilizza portAudio , che rispetto alla vrsione per ALSA, consente meno margini di manovra nella definzione dei parametri di interfacciamento. Nulla di sconvolgente, ma a mio avviso ciò rende evidente un’impronta acustica specifica di ogni sistema: Win suona diverso da OsX e da Linux, usando drivers diversi in WIn si ottengono risultati diversi,  ma in sostanza è a mio avviso possibile parlare di ‘family sound’, dove win è più brillante, LInux più scuro ed OsX ‘dorato’.

Sempre a mio personalissimo avviso e limitatamente alle prove che ho avuto l’occasione di condurre, le differenze dettate dall’hardware sono molto meno evidenti, a parità di OS e con impostazioni adeguate e l’aspetto di gran lunga più importante è certamente l’alimentazione, al punto che la soluzione più economica, come un Futro da 20 Euro su ebay o una AlixBoard alimentati da un buon lineare certamente rendono meglio di più costose soluzioni basate su moderni processori e schede madri miniITX, sulla carta vincenti.

Alcuni sostengono che la soluzione migliore in assoluto sia una motherboard miniItx + Intel I3 o I5 ed altri accorgimenti, ma sempre con alimentazione lineare. Recentemente ho visto sistemi ‘custom’ proposti a prezzi a 5 cifre, che  amio avviso stravolgono il significato minimalista di un sistema basato su squeezelite, ma ognuno è libero di perseguire la felicità  come meglio crede.

Io ritengo che una soluzione con consumi ridotti, capace di stare acessa in perpetuo e – possibilmente – di costo contenuto, sia preferibile,  però non mi hanno mai convinto quelle basate su ARM.

Da anni una AlixBoard è fissa sul secondo impianto e lasciatemi dire che è sorprendente come l’abbia via via preferita a soluzioni diverse come lo stesso Futro (thin Client) o SOC vari, sia per qualità che per bassi consumi e versatilità.  Arrivo, ripristino la corrente e lei parte, al momento di andarmene stacco il contatore e lei si spegne, senza mai una piega. Un mulo, certo, ma di gran razza.

Da circa un anno sto usando con grande soddisfazione questo minipc con installato gentoo (il processo di installazione è lungo e complicato, ma il grande lavoro degli amici di nextHardware, qui aiuta moltissimo) che al momento mi pare la soluzione preferibile tra le diverse provate, il macMini del 2009 è un’altra soluzione di tutto rispetto, ma – per i miei gusti – leggermente troppo piaciona e dorata.

Insomma, se ce ne fosse stato bisogno, le sperimentazioni con c-3po e squeezelite-R2 hanno ulteriormente dimostrato che bit perfect non è garanzia di suono uguale a se stesso su tutte le piattaforme. Ben lontano dal sapere o capire il perché, mi accontento di aver contribuito a fornire strumenti ed elementi condivisibili (e condivisi) per individuare queste differenze, che molti dichiarano frutto di autosuggestione.

Il gioco continua.

ALSA buffer size, period count e period size

Alzi la mano chi non si è mai messo le mani nei capelli dovendo indicare a squeezelite i parametri alsa (opzione -a).

Le cose sono semplici in se, ma – a mio avviso – rese complicate da ALSA ed ancor più da squeezelite, purtroppo.

Vediamo di capirle meglio.

Le opzioni sono quattro:

Buffer time (or size)
Period count (or size)
Sample format
Use mmap
Prima di vederne l’utilizzo in squeezelite, vediamo di comprenderne il significato per ALSA, lo scopo e la relazione che le lega.

Partiamo dal fondo:

MMAP (https://en.wikipedia.org/wiki/Mmap) è un metodo per muovere una porzione di dati  da una posizione di memoria ad un’altra, che in alcuni casi può aiutare a ridurre la latenza. E’ molto dubbio che in effetti lo faccia nel caso di nostro interesse e di certo NON lo fa quando l’unica cosa da fare è muovere da un buffer in ingresso ad un buffer in uscita, senza trascodifiche, che è esattamente lo spirito del nostro progetto.

Sample format specifica il formato da utilizzare per ‘aprire’ la comunicazione con la scheda audio (o il dac), le opzioni corrispondono all’organizzazione dei bit di profondità, tranne il caso particolare dei 24 e 24/3, ove 24 bit = 3 Bytes, ma solo i formati 24_3 usano effettivamente 3 bytes, quelli con 24 ne usano 4 (32 bit) scartando il meno significativo.

E’ una caratteristica del (driver della) scheda audio. Se non specificato, ALSA determina in autonomia il valore da utilizzare per la scheda audio in uso, se specificato e non corrispondente, semplicemente non funziona.

Per comprendere i rimanenti parametri, strettamente lagati tra loro, occorre inquadrare il concetto di FRAME che corrisponde all’insieme dei Bytes che rappresentano un SAMPLE (campione) nello specifico  Sample format  e per tutti i canali dello stream (2 per lo stereo, nel nostro caso).

Es.

Uno stream STEREO a 44100 Hz su 16 bit,  corrisponde ad un frame di 4 Byte, 384KHz, 32 bit a 8 Bytes, 48000 Hz / 16 5.1 canali a 12 Bytes…

Come si vede il FRAME è indipendente dal sample rate.

Il buffer di Alsa è circolare, cioè man mano che i dati vengono prelevati, nuovi li sostituiscono occupando la stessa porzione di memoria, il processo è per sua natura ASINCRONO, cioè la velocità e periodicità con cui il buffer viene svuotato e riempito possono essere diverse, il che può provocare errori di XRUN nel caso in cui il buffer non contenga abbastanza dati al momento in cui la scheda audio richiede di essere alimentata o, al contrario, se è pieno quando la sorgente tenta di scriverne di nuovi.

Nei casi di sola riproduzione, la seconda eventualità è scongiurata, quindi si parla di ‘buffer underrun‘ quando il buffer non contiene i dati richiesti.

Per minimizzare tali errori, occorre che il buffer sia sufficientemente ampio da poter alimentare l’output senza interruzioni ‘facendo fronte’ alle possibili irregolarità dell’input, ad una sua minore velocità o larghezza di banda, ricoprendo esattamente il ruolo di un serbatoio in idraulica, ma il prezzo da pagare è la ‘LATENZA‘, cioè il tempo in cui  il segnale emesso dalla sorgente impiega ad arrivare al dispositivo di output. Più grande è il buffer a parità di velocità di prelievo, più alta sarà la latenza.

Con BUFFER SIZE alsa indica la dimensione dl buffer, che può essere qualiasi, ma in pratica è sempre un multiplo del PERIOD, termine con cui alsa indica l’intervallo tra due successivi interrupt al sistema affinchè questo attivi il processo che ‘riempe’ il buffer. Essendo un processo asincrono, è misurato in FRAMES (bytes in squeezelite), per questo si parla di PEROD SIZE.

Ipotizzando -per semplicità – che i dati vengano prelevati in output con velocità costante corrispondente al sample rate, è possibile dimensionare il buffer in termini di frames e quindi di bytes ‘erogabili’ per secondo, quindi di stabilire il PERIOD SIZE in funzione della frequenza degli interrupt di sistema desiderata e sostenibile.

Es.

44100/16 -> frame 4 Bytes -> 176,4 KB/sec

384000/32 -> frame 8 Bytes -> 3072 KB/sec

Se si desidera che il sistema venga interrotto 2 volte al secondo, il PERIOD SIZE sarà rispettivamente di 88.20 e 1536 KB, 10 17,6 e 307,2 ecc.

Più elevata è la frequenza di interrupt, è più alto è il carico di CPU e più bassa la latenza.

Il rapporto tra dimensione del buffer e del period è definito PERIOD COUNT.

In sistemi minimamente moderni, non c’è nessuna reale necessità di PERIOD COUNT maggiori di 2, valori leggermente superiori rappresentano un margine di sicurezza.

E’ evidente, quindi, che il corretto dimensionamneto del buffer dipende in sostanza da due sole variabili:

a. formato dello stream (canali, bit depth e sample rate).

b. frequenza di interrupt .

Peccato che non ci sia permesso di esprimerla in questi termini…

In squeezelite, abbiamo a disposizione due coppie di parametri:

buffer size
period.
dove Buffer size può essere espresso in bytes o in ms, valori fino a 499 sono considerati ms, superiori bytes, mentre per Period valori fino a 49 sono considerati relativi al count, superiori come size.

Mentre la prima cosa è intuitiva, trattandosi solo – coosciuto il formato – di una conversione di unità di misura, la seconda è completamente diversa, cambia proprio la ‘natura’ del dato e l’effetto è diametralmente opposto:

Ponendo Buffer Size = 100 ms, a 44100/16 stereo abbiamo un PERIOD SIZE di 17,64 Kb, che avrei potuto esprimere direttamente come 17640, esprimerlo in ms ha il vantaggio di essere indipendente dal formato, quindi è a mio avviso preferibile.

Ponendo period a 49,  viene interpretato come count,  da cui il period size risulta essere 17640/49= 360 byte, inserendo, invece,  51, viene interpretato come bytes, il che porta ad un period count di 17640/51 = 346 !!!

Fortunatamente, nessuno di questi valori è effettivamente usato da ALSA come tale, che calcola il valore accettabile ‘più vicino’ e lo utilizza,   squeezelite ne fornisce feedback nel log.

Se non si specifica nulla, squeezelite utilizza i seguenti valori di default:

Buffer Size: 40 ms
Period Count: 4
che sono etremamente conservativi.

Sconsiglando vivamente di indicare la dimensione del buffer e/o del period in bytes, così da rimanere indipendenti dal formato in ingresso ed in uscita, lascio a voi la sperimentazione dei valori più indicati per il vostro impianto ed il vostro gusto, segnalando che c’è una generale concordanza nel considerare valori bassi di buffer size / alti di perido count come tendendi a produrre un suono più brillante e veloce, mentre valori più elevati buffer size / ridotti di period count risulterebbero più smooth,  ma molto dipende da altri parametri, buffer applicativi in primis, per i quali valgono analoghe considerazioni.

Concludo con una nota sulla latenza.

In sistemi di acquisizione audio multicanale, la latenza è un parametro fondamentale, immaginate il caos che si produrrebbe con latenze di quache decimo di secondo tra i diversi strumenti, la voce o anche solo le spie sul palco… Stesso dicasi per sistemi di riproduzione multicanale ma indipendenti, anche se in questo caso non è tanto la latenza in se ad essere importante, quanto il ‘delta’ di sincronizzazione, comunque prodotto, di cui la latenza è solo una delle cause.

Ma in un sistema mono o multicanale su uno stesso flusso (come nel nostro caso) l’unico effetto della latenza è un minimo ritardo COMUNE a tutti i canali che rimangono perfettamente sincronizzati, in che misura è un male per se? A mio avviso praticamente nulla e scambio volentieri qualche decimo di secondo di latenza per la virtuale immunità da xRun ed un minore utilizzo della CPU.

Squeezebox server è un sistema multiroom che consente di sincronizzare diversi players, in questa applicazione – teoricamente – la latenza assume un significato maggiore, ma le irregolarità dei diversi clock provocano differenze di ordine maggiore, per contrastare le quali LMS si è dotato di un protocollo specifico che garantisce l’allineamento temporale di diversi player, minimizzandone  (per quanto possibile) l’effetto.

RImane comunque un problema irrisolto ed irrisolvibile a priori senza l’adozione di un ‘master clock’ di rete condiviso (v. Ethernet AVB), preoccuparsi della latenza in questo contesto è come cercare la mitica pagliuzza avendo una trave nell’occhio.

p.s.

Per chi fosse interessato, la mia attuale configurazione dei parametri di alsa è la seguente:

40:2::0.

Squeezelite-R2 è nella versione ufficiale di squeezelite

E’ con grande soddiisfazione  che annuncio l’integrazione della modifica che ha originato squeezelite-R2 in tutte le versioni di squeezelite manutenute da Rakph Irving,  che è il nuovo manutentore ‘ufficiale’ di squeezelite, come indicato anche nell’help di squeezebox server.

Questo significa che ogni verisone successiva alla 1.8.3-709 comprende l’opzione -W che si comporta esattamente come squeezelite-R2, consentendo il playback di flussi PCM decodificati e ricampionati sul server.

Da subito, tutte le versioni sono compatibili con C-3PO, anche se questo continua ad emettere un messaggio di promemoria, non essendo possibile verificare se l’ozpione -W sia effettivamente attiva. DI fatto, ho personalmente testato e verificato tutte le versioni binarie con esito positivo.

A mio avviso è un   vantaggio per tutta la comunità avere un’ unica versione di riferimento, in particolare per gli utilizzatori, dato che:

1.da subito, sono disponibili le versioni binarie per molte piattaforme aggiuntive, tra cui ARM,

2. nel medio lungo termine, anche dovessi ‘abbandonare’ il progetto, avrete la certezza della continuità.

3. Il ‘parco’ di utilizzatori si amplia enormemente, si parla di almeno 10.000 installazioni di squeezelite attive oggi e presumibilmente sono molte di più, quindi ogni eventuale ‘errore’ residuo viene scoperto e risolto molto più velocemente.

4. Qualsiasi ‘innovazione’ apportata a squeezelite sarà direttamente disponibile, senza bisogno di un mio intervento.

In merito a questo ultimo punto, segnalo però una controindicazione: buona parte delle funzionalità aggiunte al ‘nucleo’ di squeezelite sono di certo utili per qualcuno, ma non ‘minimaliste’ in senso stretto, squeezelite-R2 mantiene quindi un suo significato, come versione compatibile ma separata, con vocazione minimalista, per chi è interessato a questo aspetto.

Decidete con tranquillità quale versione utilizzare, nella certezza di ottenere da subito un ottimo risultato e la piena compatibilità in futuro.

NOTA BENE: Ralph – ad oggi – non ha inserito nelle sue versioni l’opzione -x di Daphile per impedire il downsampling sul server, se utilizzata in squeezelite produce un errore, è bene saperlo e considerarlo.

C-3PO LMS Plugin e Squeezelite-R2: obiettivi e limiti del progetto

Come già anticipato,  lo scopo di tutto è poter fare decode in PCM e resampling sul server (Logitech media server) e di conseguenza alimentare il player (Squeezelite-R2) con uno stream già nel formato desiderato, così da renderne realmente leggerissimo il carico.

Questo perchè sono personalmente convinto che è quello che sta vicino all’impianto (il player) a dover essere curato maggiormente in modo da evitare ‘inquinamenti’ di qualsiasi sorta, mentre – sempre a mio avviso – ciò che avviene su un server a decine di metri di distanza, in un’altra stanza e possibilmente alimentato su un’altra linea elettrica è sicuramente ordini di grandezza meno influente, ammesso che lo sia in alcun modo.

Applicando la forma del dialogo con un (nemmeno troppo) ipotetico audiofilo, spero di chiarirne le caratterisiche.

L’audiofilo: Ma… non si poteva già fare?

No, LMS non trasmette ai client informazioni attendibili sullo stream quando il formato è PCM (raw, wav o aif che sia). Squeezelite in versione originale, si adegua e di conseguenza non è in grado di riprodurre correttamente stream ricampionati.

Fino a ieri si era costretti a scegliere:

a. Usare Flac o altri formati non PCM.
b. Lasciare il compito del resampling al client.

La modifica a Squeezelite consente proprio di ‘analizzare’ lo stream in ingresso per determinarne – quando possibile – in autonomia il formato e riprodurlo correttamente.

L’audiofilo: Ma non è una novità, Daphile lo fa gia.

Kimmo, mantainer di Daphile, è stato uno dei primi a capire le potenzialità della modifica ed adottarla. Le versioni di Daphile dal 4 di ottobre in poi la integrano.

L’audiofilo: Non lo sapevo, non lo si legge da nessuna parte

Già, è’ così…

L’audiofilo: E C-3PO, il plugin,  a cosa serve?

Per ‘comandare’ il server era fino ad oggi necessario modificare manualmente alcuni files di configurazione, con risultato spesso catastrofici o almeno non certi (spesso ci si illude di aver modificato il comportamento del server, ma non è così).

ll plugin C-3PO in prima battuta realizza un’interfaccia grafica più intuitiva per impostare i parametri necessari per gestire le operazioni di decodifica e ricampionamento sul server, eliminando la necessità di intervenire a livello di file di configurazione.

Oltre a questo, permette di configurare e metter in atto opzioni di ricampionamento in funzione del formato (non solo il ‘tipo’, ma anche la frequenza di campionamento originale, ad esempio) del file o stream in ingresso, cosa prima non possibile sul server.

L’audiofilo: Anche questo Daphile lo fa gia, usa lo stesso plugin?

Al momento non mi risulta che Daphile sia in grado di fare ricampionamento selettivo sul server, lo ha sempre fatto ma solo usando squeezelite. Usa un meccanismo esterno a Logitech media server e proprietario, non C-3PO plugin, che io sappia.

Chiunque può adottare il mio plugin nel rispetto delle regole imposte dalla licenca GNU GPL v2 che regola l’utilizzo, la modifica, integrazione e distribuzione di Logitech Media Server e Squeezelite (open source / free software), non è lo stesso per le componenti proprietarie di Daphile o altri sistemi.

L’audiofilo: Quali formati sono supportati?

Al momento AIF, FLAC e WAV (pcm), il piano è di aggiungere tuttii formati lossless significativi supportati da LMS, nessuna previsione per i formati lossy, ma non sarebbe un problema farlo.

L’audiofilo: Non supporta DSD?

Esiste già un plugin analogo (DSDPlayer) realizzato da Kimmo Taskinen (Daphile) e modificato da Adrian Smith (Triode, squeezelite) che lo fa, ho ritenuto corretto non sovrappormici, dato che possono tranquillamente convivere. Non ci sono incompatibilità o limiti tecnologici, se si evidenzia una necessità, è fattibile senza problemi.

L’audiofilo: Ma, alla fine, perchè dovrei utilizzare C-3PO e Squeezelite-R2?

Sono strumenti open source, multipiattaforma e perfettamente integrati nell’ecosistema squeezebox, il che abilita alla fruizione di tantissime altre funzionalità che altri hanno reso o renderanno via via disponibili secondo la migliore tradizione della squeezebox community, senza scopi di lucro ne intenti commerciali.

Rispeto a soluzioni proprietarie, sono estremamente più indipendenti da me e dalla mia disponibilità futura di tempo per mantenerli

L’audiofilo: Esiste una ISO da scaricare?

No, si tratta d componenti, non di un sistema completo.

Spero e credo ne saranno rese disponibili a breve, al momento esistono delle ottime guide di riferimento e di installazaione cui fare riferimento.

L’audiofilo: Come faccio ad averli?

Sono gratuiti oltre che liberi, la guida all’installazione riporta i link dove recuperare le versioni necessarie. Il codice sorgente, i termini di licenza e le versioni eseguibili per le diverse piattaforme sono in gitHub. C-3PO si installa direttamente da LMS come qualsiasi altro plugin, fare riferimento alla guida per ulteriori informazioni

Powered by WordPress & Theme by Anders Norén