AudioLinux - un nuovo Sistema Operativo per HQPlayer, ma non solo

[bibo01]

Basato su Archlinux, AudioLinux è un sistema operativo che è stato concepito per ottenere la massima qualità nella riproduzione audio.
Possiede un kernel realtime e quest'aspetto, più che la latenza vera e propria, m'interessava perché un RTOS permette di stabilire priorità degli IRQ e ottimizzare le risorse da fornire a determinate applicazioni. Nel nostro caso un sistema basato su HQPlayer, oltre alla capacità di calcolo, ha infatti bisogno di I/O ottimizzato. In poche parole, altri OS generalisti come OSx e Windows nelle sue varie versioni hanno bisogno di programmi esterni per diventare "audiofili", mentre AudioLinux al contrario nasce già con questa vocazione, snello e dedicato.



Per l'audio high-end quello che importa non è il ritardo (latenza audio) tra l'invio del segnale e la sua riproduzione. Un segnale con un ritardo di 20 ms ma che mantiene costante tale ritardo nel tempo avrebbe lo stesso effetto positivo di un segnale che mantiene un ritardo di 1ms (a meno che non dobbiamo suonare su una tastiera!). E' proprio per questo fatto fondamentale della non variazione del ritardo che un kernel realtime può essere decisivo per una corretta riproduzione audio.

Da questo punto di vista le misure su AudioLinux con un processore non dei più recenti, con IRQ per il device, utilizzando l'applicazione rtapp (vedere https://aur.archlinux.org/packages/rtapp/), sono di questo tipo (le cifre sono in microsecondi):

STANDARD TEST
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 25.81 14.02 5.39 1/272 1882

T: 0 ( 1879) T: 1 ( 1880) T: 2 ( 1881) T: 3 ( 1882)

P:98 P:98 P:98 P:98

I:100 I:100 I:100 I:100

C: 10000 C: 10000 C: 10000 C: 9989

Min: 1 Min: 1 Min: 1 Min: 1

Act: 2 Act: 2 Act: 1 Act: 1

Avg: 2 Avg: 2 Avg: 2 Avg: 2

Max: 11 Max: 30 Max: 19 Max: 9

STRESS TEST
Running in process mode with 10 groups using 40 file descriptors each (== 400 tasks)
Each sender will pass 10000 messages of 100 bytes
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 25.81 14.02 5.39 89/675 2288

T: 0 ( 1939) T: 1 ( 1978) T: 2 ( 2015) T: 3 ( 2060)

P:98 P:98 P:98 P:98

I:100 I:100 I:100 I:100

C: 10000 C: 10000 C: 10000 C: 9965

Min: 2 Min: 2 Min: 2 Min: 2

Act: 4 Act: 4 Act: 3 Act: 4

Avg: 4 Avg: 4 Avg: 3 Avg: 3

Max: 11 Max: 16 Max: 13 Max: 11

I numeri rappresentano la latenza del processore. Un sistema lavora alla perfezione (realtime) se nello STRESS TEST e nello STANDARD TEST i numeri sono dello stesso ordine di grandezza. Se invece nello STRESS TEST sono inferiori rispetto allo STANDARD vuol dire che nella maggior parte dei casi della riproduzione audio il processore non sta usando tutte le sue capacità. Test effettuato su suggerimento di jhernberg, "maintainer" dell pacchetto linux-rt per Arch.
--> informazioni dettagliate qui: https://rt.wiki.kernel.org/index.php/Cyclictest

Qui invece riporto il monitoraggio degli IRQ con HQplayer (DSD 128 nativo da file 44,1 kHz) prima in pausa e poi in riproduzione:
IRQ=16
HARDWARE DEVICES:
IO-APIC 16-fasteoi ehci_hcd:usb1
--> EHCI Host Controller, iFi (by AMR) HD USB Audio,

IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0 IRQs/Second --> 0

IRQs/Second --> 1890 IRQs/Second --> 1895 IRQs/Second --> 1889 IRQs/Second --> 1913 IRQs/Second --> 1901 IRQs/Second --> 1878 IRQs/Second --> 1906 IRQs/Second --> 1881 IRQs/Second --> 1900 IRQs/Second --> 1908 IRQs/Second --> 1907

Forse qualcuno immagina che AudioLinux sia nient'altro che un'installazione di Archlinux più qualche script ad hoc - assolutamente sbagliato. In realtà il lavoro per la preparazione di AudioLinux va molto più in profondità ed è piuttosto complicato. Infatti, l'installazione di Archlinux è lunga e laboriosa, ed è dettata dalla scelta degli autori di Archlinux che l'utilizzatore deve conoscere tutte le caratteristiche dell'installazione. Inoltre, Archlinux installa un sistema-base senza GUI, per cui un ambiente come LXQt deve essere installato successivamente. La "taratura" di tale ambiente grafico, soprattutto l'uniformità dei temi tra qt4, qt5, gtk2, gtk3, ecc., è un lavoro piuttosto lungo e complesso. In AudioLinux esistono numerose speciali configurazioni, come ad esempio la configurazione della rete con netctl-gui; il kernel realtime Linux-RT è compilato manualmente con l'opzione "performance"; la modifica del valore max_user_freq per rtc0 e hpet; l'ottimizzazione per processori Intel volte ad ottenere le massime prestazioni dalla CPU senza che questa vada mai in power saving; l'utilizzo di prelink per il lancio veloce dei programmi; l'utilizzo di alcune unità systemd per velocizzare il boot; il desktop con tutti i comandi importanti a portata di mano; ecc. ecc.

Oltre ai suddetti motivi, ci sono parecchi altri aspetti che mi hanno portato a testare AudioLinux, i principali sono:

1. la possibilità di usare un client su smartphone/tablet per avere playback tramite HQPlayer;
2. la possibilità di poter utilizzare lo stesso OS sul NAA, unendo ottimizzazione ad essenzialità;
3. la presenza di un Ramdisk intelligente già pronto;
4. la possibilità di poter utilizzare lo stesso sistema per A/V, variando le ottimizzazioni con un semplice click.

Tutto questo sulla carta è interessante, ma non essendo io un Linux guru e non essendo ArchLinux un OS per neofiti, AudioLinux deve essere il più possibile di facile utilizzazione. Sono pronto a dedicarci del tempo per configurarlo, se intuitivo, ma certamente non se devo stare difronte ad una finestra terminale ad "impazzire" con terminologia varia.

------------------------------------------------------------------------

Veniamo alla prova pratica. Suggerisco di stampare la Mini Guida dal sito di AudioLinux e tenerla a portata di mano.

L'autore di AudioLinux è hifi25nl, un nexthardwariano di nome Piero, che molto gentilmente mi ha mandato una pennetta USB preinstallata.
Per fare un po' di pratica con il nuovo sistema, la inserisco nel mio notebook, invece del PC principale e, dopo la schermata di boot,...WOW, ecco il desktop in 13 secondi! ...e funziona tutto al primo colpo!!!
A dire il vero la scheda audio interna è in blacklist, giustamente disabilitata, ma per questa prima prova ne ho bisogno. Per cui vado in /etc/modprobe.d/blacklist-minimize.conf, lo apro tramite pulsante dx e tolgo la voce "blacklist snd_hda_intel", lancio HQPlayer, seleziono un brano ed è...Musica.



Qualche consiglio iniziale -

• Il desktop di AudioLinux è configurato per 1920x1080. Il mio notebook è partito a 1366x768 e non vedeva le due colonne di icone a dx e la riga di icone in basso, nonostante abbia provato a cambiare configurazione del monitor in LXQt System Settings (LXQt è la GUI); quindi, basta riposizionare le icone.
• Per riposizionare le icone, spostatele dalla parte opposta e poi nella posizione finale.
• L'icona reboot Command Line sarà utilizzata per l'NAA e disabilita la GUI.
• In LXQt System Settings non è possibile accedere a Date & Time e User & Groups. Comunque, l'ora si aggiusta da sola collegandosi ad internet e l'altro verrà messo a posto in un prossimo aggiornamento della GUI.
• Se sul proprio HD si ha un'installazione Windows, l'icona 2Windows chiude AudioLinux e riavvia il sistema sotto Windows. Funziona perfettamente.
• Se sull'hard disk sono presenti due installazioni di Windows (tipo 8.1 e Server) bisognerebbe cambiare come ROOT ** i file
  /boot/syslinux/syslinux.cfg (per sistemi non uefi)
  /boot/EFI/boot/syslinux.cfg (per sistemi uefi)
  Adesso ad esempio c'è una sezione con
  LABEL windows
  
  MENU LABEL Windows
  COM32 chain.c32
  APPEND hd1 0
  Se il secondo windows è sullo stesso hard disk ma in una differente partizione, aggiungere subito dopo un'altra sezione tipo
  LABEL windows2
  
  MENU LABEL Windows2
  COM32 chain.c32
  APPEND hd1 1
  dove hd1 è l'hard disk e "0" e "1" sono le differenti partizioni
  Ovviamente se vi sono più hard disk bisognerà capire quale è hd1, quale hd2, ecc.
  --> Procedere con cautela: un errore sul file syslinux.cfg potrebbe condurre all'impossibilità di fare il boot.

I primi due passi da fare sono:

• "montaggio" dell'hard disk o NAS della nostra libreria musicale
• settaggio della scheda ethernet.

Entrambi i punti sono spiegati in dettaglio nella Mini Guida. Il passo successivo è l'ottimizzazione del sistema.


** Per andare ROOT da terminale: scrivere "su" poi < invio > poi password "audiolinux0"
oppure
sulla barra in basso ci sono due icone di gestore dei file, quella più a destra lancia Pcmanfm-qt come root e richiede la password "audiolinux0".

[bibo01]

Delle ottimizzazioni di AudioLinux under the hood abbiamo acccennato in precedenza, ora passiamo a quelle alla portata dell'utente.

Il nostro obiettivo è definire una procedura sia per:

• PC Server (input Ethernet, output USB, applicazione HQPlayer)-->DAC
• PC Server (input/output Ethernet, applicazione HQPlayer)-->NAA (input Ethernet, output USB, applicazione NAD)-->DAC.

Esisto due categorie principali: il Real Time e la Minimizzazione dei servizi disponibili.



Per il Real Time

• rtirq assegna le priorità degli IRQ dell'hardware e quella del clock realtime rtc0
• rtapp assegna la priorità delle applicazioni audio.

Vediamo il file di configurazione di rtapp in /etc/rtapp/rtapp.conf tramite pulsante dx del mouse:
----------
APPLICATIONS="mpd hqplayer hqplayerd mediacenter20 networkaudiod deadbeef linuxsampler ardour-3.5.403 rosegarden"

MAX_PRIORITY="80"

MODE="autodec"
-----------
Nella lista APPLICATIONS si può mettere tutto ciò che si vuole. rtapp assegnerà le priorità partendo dalla prima in ordine decrescente se il MODE è autodec. Ovviamente, le applicazioni che sono presenti nella riga ma che non sono state avviate non vengono prese in considerazione. Poiché inoltre autodec è in modalità "automatica" la MAX_PRIORITY della seconda riga non viene utilizzata. (per altre opzioni consultare il readme.txt)

Vediamo ora quello che ci interessa principalmente dato che l'ottimizzazione RT passa dalla seguente configurazione - cioè alcune righe relative al file di configurazione di rtirq in /etc/conf.d/rtirq (settato su modalità extreme):


----------
RTIRQ_NAME_LIST="rtc usb6"

# Highest priority.
RTIRQ_PRIO_HIGH=95

# Priority decrease step.
RTIRQ_PRIO_DECR=2
----------
Poiché ci sono solo due termini in RTIRQ_NAME_LIST e la RTIRQ_PRIO_HIGH è 95 e il "passo" è 2, le assegnazioni delle priorità nel caso di HQPlayer sono le seguenti:
rtc0 95
usb6 93
HQplayer 91

Importante - se il computer come probabile possiede molte usb, bisogna specificare esattamente la presa USB interessata, altrimenti potremmo arrivare ad una situazione non corretta come questa:
rtc0 95 usb1 93
usb2 92
usb3 91
usb4 90
usb5 89
usb6 88
HQplayer 91

In questo caso, supponendo che il DAC sia collegato alla usb6, HQplayer avrebbe una priorità maggiore della porta USB, cosa non auspicabile.
Per verificare a quale porta è collegato il DAC è sufficiente lanciare da linea di comando rtstatus. Si avrà una riga del tipo

USB6 IRQ=23 HiFimeDIY Audio SA9023 USB Audio, SA9023 USB Audio, UHCI Host Controller

Da questa riga si evince che il DAC è collegato alla presa usb6, quindi in RTIRQ_NAME_LIST si dovrà specificare solo la porta USB collegata al DAC che nel nostro caso è USB6.
--> tutto questo sarebbe molto complicato senza l'applicazione rtstatus



I due script rtapp.conf.standard ed extreme sono uguali non per errore ma perché si desidera lasciare all'utilizzatore la scelta.
In realtà con l'opzione "autodec", come dicevo prima, il parametro 80 è irrilevante e le due configurazioni sarebbero comunque di fatto uguali.

In pratica, sia per RT che Minimizzazione, l'idea è quella di configurare sempre e solo i file presenti in /home/audiolinux/Programmi/alsa-jack e poi applicare le configurazioni cliccando sulle icone corrispondenti sul Desktop, in questo caso /home/audiolinux/Desktop/Realtime/RT priority extreme oppure /home/audiolinux/Desktop/Realtime/RT priority standard (senza utilizzare root per fare l'editing diretto di /etc/conf.d/rtirq e /etc/rtapp/rtapp.conf).
I file quindi che si devono eventualmente modificare sono nella directory /home/audiolinux/Programmi/alsa-jack/ e cioè

• rtapp.conf.extreme
• rtapp.conf.standard
• rtirq.conf.extreme
• rtirq.conf.standard

Si potrebbe quindi modificare rtirq.conf.extreme o rtirq.conf.standard in questo modo (rtapp assegnerà le priorità automaticamente):

1. PC Server con input Ethernet per NAS e output USB per DAC con applicazione HQPlayer
   
   RTIRQ_NAME_LIST="rtc usbx enp0s25" (sostituire a usbx l'effettiva USB del DAC, qui si suppone che Ethernet sia stato assegnato il nome enp0s25)
2. PC Server con input Ethernet per NAS e output Ethernet per NAA
   
   RTIRQ_NAME_LIST="rtc enp0s25"
3. NAA con input Ethernet per il segnale proveniente dal PC Server e output USB per il DAC con applicazione networkaudiod
   
   RTIRQ_NAME_LIST="rtc usbx enp0s25" (sostituire a usbx l'effettiva USB del DAC, qui si suppone che Ethernet sia stato assegnato il nome enp0s25)

Non è detto che il nome della connessione ethernet sia enp0s25.
Per conoscere i nomi delle connessioni digitare da terminale: ip addr show (scartare la connessione "lo" di loopback)

Possono essere ipotizzati collegamenti differenti, ad es. con librerie musicali su SATA o USB, ma la procedura è la medesima. Dobbiamo ricordarci soltanto che la priorità delle porte I/O è come un fiume che deve ingrandirsi man mano che arriva alla foce (il DAC).

------------------------------------------------

Nella cartella Minimize-Maximize troviamo lo script /home/audiolinux/Programmi/alsa-jack/Maximize-minimize/minimize.sh che a noi interessa per - udite, udite - minimizzare il sistema, attivando/disattivando servizi. Ciò che andremo a disabilitare dipende esclusivamente dalla configurazione prescelta per il nostro sitema.



Nella prima parte dell'elenco possiamo disattivare driver e programmi come VNC.

La seconda parte permette di disattivare servizi. Questo è l'elenco:

• systemctl disable avahi-daemon.service
  
  --> https://wiki.archlinux.org/index.php/avahi, personalmente lo lascio sempre disabilitato perché utilizzo invece samba
• systemctl disable lircd.service
  
  --> https://wiki.archlinux.org/index.php/LIRC, è il servizio lirc per il telecomando. In molti casi è inutile perché il telecomando può funzionare direttamente con il kernel linux.
• systemctl disable lm_sensors.service
  
  --> https://wiki.archlinux.org/index.php/Lm_sensors, serve per monitorare la temperatura del processore e altri parametri.
• systemctl disable nmbd.service
• systemctl disable smbd.service
  
  --> https://wiki.archlinux.org/index.php/Samba, nmbd e smbd sono servizi fondamentali per accedere agli hard disks sia windows che linux, personalmente li lascio sempre attivati (ovviamente se l'hard disk del NAS ad esempio viene "montato" al boot con fstab se ne potrebbe fare a meno)
• systemctl disable httpd.service
  
  --> https://wiki.archlinux.org/index.php/Apache_HTTP_Server, è il servizio per far funzionare il computer da web server, disabilitato.
• systemctl disable sshd.service
  
  --> https://wiki.archlinux.org/index.php/Secure_Shell, da lasciare sempre abilitato per poter accedere al computer via linea di comando da un altro computer. Nel caso di audiolinux bisognerà digitare, da linea di comando, "ssh audiolinux@" e poi digitare la password audiolinux quando viene richiesta.
• #systemctl disable minimserver@audiolinux
  
  --> MinimServer, Servizio da abilitare per far funzionare HQplayer embedded e comunque per avere un server UPnP.
• #systemctl disable networkaudio@audiolinux
  
  Servizio da abilitare per lanciare automaticamente HQplayer network daemon al boot

[bibo01]

HQPlayer è il music player preferito di AudioLinux e...si vede!
A onor del vero, è in grado di supportare al meglio anche vari altri players, tipo mpd, JRiver...

In precedenza avevamo citato i principali motivi per i quali questo RTOS può interessare agli utenti di HQPlayer. Vale la pena di ricordarli:

1. la possibilità di usare un client su smartphone/tablet per avere playback tramite HQPlayer;
2. la possibilità di poter utilizzare lo stesso OS sul NAA, unendo ottimizzazione ad essenzialità;
3. la presenza di un Ramdisk intelligente già pronto;
4. la possibilità di poter utilizzare lo stesso sistema per A/V, variando le ottimizzazioni con un semplice click.

Il 1) è già ben spiegato nella Guida di hifi25nl che illustra l'uso di HQPlayer Embedded.

Questo è un video di HQPlayer Embedded controllato da uno smartphone:



Aggiungo soltanto che sul desktop c'è l'icona "HQplayer embedded READ FIRST!.txt" che spiega esattamente la procedura.
Basta cliccare:

• l'icona sul desktop "enable Minimserver at boot"
• poi, cliccare su una delle configurazioni nella cartella "HQplayer embedded" (dopo aver controllato che l'indirizzo hardware nel corrispondente file xml sia corretto)

Una volta che il tutto funziona si può controllare HQplayer Embedded anche dal laptop con il programma eezUPnP nella cartella Audio del Desktop.

-----------------------------------------

Il 2) è di facile implementazione, se avete seguito le nostre istruzioni. Come spiegato nella Mini Guida, una volta verificato il tutto possiamo riavviare il sistema in modalità terminale. Consiglio prima un test con l'icona "reboot COMMAND LINE" che lo fa una sola volta (cioè al reboot successivo ritorna al default in modalità GUI) e solo successivamente in modo permanente.
Per cambiare, invece, il default bisogna cambiare (come root) il file /boot/syslinux/syslinux.cfg (per BIOS classico) o /boot/EFI/boot/syslinux.cfg (per UEFI)
La riga è:
DEFAULT archRT
Le opzioni sono: archRT, archCL (commandline), arch, windows.

-----------------------------------------

Per il 3), se desideriamo copiare HQplayer in Ramdisk, dobbiamo copiarlo da /usr/bin/hqplayer a /home/audiolinux/Music/Music_ramdisk/.



Per networkaudiod faremo altrettanto prendendolo dalla stessa directory.
Il sistema Ramdisk è già predisposto per ricaricare i file in RAM al riavvio successivo.

-----------------------------------------

Il 4) può essere molto utile agli utenti che usano il proprio sistema anche per A/V.
AudioLinux è predisposto per ottimizzare il playback video tramite lo script Maximize; inoltre, permette di utilizzare il client Unified Remote per VLC, basta cliccare l'icona sul desktop "enable Unified Remote at boot".
Se si possiede un NAA, bisogna staccare il cavo USB che va al DAC e attaccarlo direttamente al PC Server.
Si spera che in futuro sia possibile implementare il playback A/V utilizzando HQPlayer Embedded come render audio, così come avviene per la sola Musica.

[bibo01]

Il primo test di ascolto di AudioLinux è stato fatto con un notebook Sony Vaio, paragonandolo a Windows 7, con HQPlayer su entrambi i sistemi.
Il notebook andava a batteria e su Win 7 era attivo Fidelizer v6.6 per avere un minimo di snellimento anche su questo OS.
Il resto dell'impianto era composto da Onyx DAC25A, pre Angstrom Research Stella, finali Rowland Research Model 7 Mono Gold Edition, diffusori Spendor BC1.

Ad essere sincero il DAC utilizzato ha fatto un po' le bizze nel riconoscimento sia sotto Windows che AudioLinux. Però per il poco che sono riuscito ad ascoltare - solo un paio di ore - sia io che un altro amico esperto (lui non era al corrente del tipo di test che stavo facendo) abbiamo avuto la sensazione di una maggiore precisione di AudioLinux nella riproduzione sonora, un po' più preciso negli attacchi e, forse, una maggiore pulizia. Il mio amico, che non è un amante di musica liquida, si è meravigliato per la buona riproduzione

Prossima fermata confrontare AudioLinux con Windows 8.1 e Windows Server 2012 R2 sul mio sistema principale
...a seguire AudioLinux vs WS core mode sul Fitlet-B come NAA

--------------------------------------------------------------

Il secondo test di ascolto di AudioLinux è anche quello decisivo perché fatto in condizioni normali nella mia stanza usuale con il sistema principale. L'impianto è composto da LKS Audio DAC (doppio ES9018), Sanders Magtech, Magneplanar Mini Maggies.

La sorgente è un PC assemblato i7 4790 con HQPlayer Desktop v.3.7.1 su AudioLinux e su Windows Server 2012 R2. Ho provato sia con Cubox-i NAA + LPS che senza. Inoltre, ho testato MinimServer installato su NAS e HQPlayer Embedded + Rygel sul PC, comandando il tutto da tablet tramite BubbleUPnP.

Confrontando AudioLinux con Windows Server (GUI) ho evidenziato alcune differenze, non enormi ma sostanziali. Il primo ha presentato una risposta più controllata, meno impulsiva ed aspra, più levigata e, in fin dei conti, più piacevole rispetto al secondo. Forse il secondo ha una riserva di miglioramento possibile attraverso ottimizzazioni varie - vedi AO, JPlay e Ramdisk. Quest'ultimo accorgimento non l'ho testato perché volevo mettere i due OS in condizioni il più simili possibili. Comunque, il Ramdisk è già abilitato anche sotto AudioLinux e basta trascinare files o applicazioni nella cartella stabilita.

Le stesse differenze sono state evidenziate passando dal collegamento diretto USB DAC a quello tramite Cubox-i NAA. Nel mio impianto l'uso di un Cubox-i NAA non stravolge il suono, ma aggiunge più naturalezza. Inoltre, un alimentatore lineare, invece dello switch di serie, ha reso il suono ancora più organico.

In ultima battuta desidero aggiungere che utilizzare Embedded e controllare la propria libreria musicale tramite BubleUPnP è una vera e propria goduria per i control freak, soprattutto se si vuole avere un impianto headless. Per il cambio dei settings, basta prepararsi una serie di pre-settaggi per HQPlayer Embedded e selezionarli di volta in volta. Sul questo tema forse è in arrivo un'applicazione multi-piattaforma da parte di Geoffrey Armstrong che manderà playlist direttamente a HQPlayer, rendendone possibile il controllo remoto.

Prossima fermata testare il Fitlet-B come NAA con Windows Server e AudioLinux

TO BE CONTINUED

[audiodan]

E bravo il mio socio! Grande lavoro, bibokan, soprattutto per la descrizione veramente minuziosa. Attendo con ansia le prove comparative future, chissà se non sia la volta buona che mi converta alla "vera religione"...........
Certo che convincermi a cambiare il suono che esce in questi giorni dai miei diffusori sarà dura, ma chissà.......anche noi infedeli qualche volta ci facciamo convincere...........con le buone........
Complimenti anche a hifi25nl per il lavoro svolto, che a naso mi sembra di poter dire essere assai ben fatto ma soprattutto pensato da appassionato di hifi più che da informatico.

[EuroDriver]

E bravo il mio socio! Grande lavoro, bibokan, soprattutto per la descrizione veramente minuziosa. Attendo con ansia le prove comparative future, chissà se non sia la volta buona che mi converta alla "vera religione"...........
Certo che convincermi a cambiare il suono che esce in questi giorni dai miei diffusori sarà dura, ma chissà.......anche noi infedeli qualche volta ci facciamo convincere...........con le buone........
Complimenti anche a hifi25nl per il lavoro svolto, che a naso mi sembra di poter dire essere assai ben fatto ma soprattutto pensato da appassionato di hifi più che da informatico.

+ 1

This is great stuff ! Unquestionably the right approach for the long run. Audiophiles need a realtime OS to get the timing precise !

[bibo01]

+ 1

This is great stuff ! Unquestionably the right approach for the long run. Audiophiles need a realtime OS to get the timing precise !

Why don't you have a try?!
You can keep AudioLinux on USB flash drive and run it from there without modifying your main HD. Insert it in a USB 3 port and this Sandisk Extreme USB stick can do up to 245 MB/sec.

[Ipoci]

...Prossima fermata confrontare AudioLinux con Windows 8.1 e Windows Server 2012 R2 sul mio sistema principale ...a seguire AudioLinux vs WS core mode sul Fitlet-B come NAA

TO BE CONTINUED

Attendo il confronto con il sistema principale.

Avevo avuto un bagliore di speranza di poter installare AudioLinux sul NAA Acme ma purtroppo nisba, c'e' dietro troppo lavoro da fare ... peccato. Al momento quindi, l'idea di mettere un NAA "evoluto" con su AudioLinux non e' che mi entusiasma.

Un cordiale saluto, Massimiliano

[bibo01]

Ho appena letto un post di Miska e forse è possibile implementare HQPlayer Embedded + Rygel in ambiente no-GUI...

[Maggio]

...Prossima fermata confrontare AudioLinux con Windows 8.1 e Windows Server 2012 R2 sul mio sistema principale ...a seguire AudioLinux vs WS core mode sul Fitlet-B come NAA

TO BE CONTINUED

Sono curioso del risultato.