Il mio nuovo gioiellino

[giuca70]

Ora con la 2.00 devo provare, prima era quasi un obbligo. Mi accingo..

Ho appena collegato direttamente al 4,4 la cuffia, che prima era connessa all'ampli iHA-6.... sempre in bilanciato.

Non una cuffia qualunque, di proposito una delle più onnivere.

La Hifiman HE6seV2 con bassa impedenza e bassa efficienza planare.

Il KA17 in d.mode non sfigura affatto al cospetto di un ampli carrozzato.

Chiaramente vol 60su 60 senza clipping o distorsioni.

Mette 8 stadi in parallello 2 a 2 in d.mode, ciuccia oltre 2,5 watt  eppero' suona eccome se suona.

Disattivando il d.mode è come avere esattamente metà volume e meta' dinamica.

Prima era un citofono.

Merito della V2.

Chiaramente è in condizioni limite, ed il fatto che non sfigura la dice lunga.

La HEseV2 attaccata al iHA-6 ed ovviamente esprime meglio tutto, ma questo è ovvio.

[Uncino]

1 ora fa, giuca70 ha scritto:

Ora con la 2.00 devo provare, prima era quasi un obbligo. Mi accingo..

Ho appena collegato direttamente al 4,4 la cuffia, che prima era connessa all'ampli iHA-6.... sempre in bilanciato.

Non una cuffia qualunque, di proposito una delle più onnivere.

La Hifiman HE6seV2 con bassa impedenza e bassa efficienza planare.

Il KA17 in d.mode non sfigura affatto al cospetto di un ampli carrozzato.

Chiaramente vol 60su 60 senza clipping o distorsioni.

Mette 8 stadi in parallello 2 a 2 in d.mode, ciuccia oltre 2,5 watt  eppero' suona eccome se suona.

Disattivando il d.mode è come avere esattamente metà volume e meta' dinamica.

Prima era un citofono.

Merito della V2.

Chiaramente è in condizioni limite, ed il fatto che non sfigura la dice lunga.

La HEseV2 attaccata al iHA-6 ed ovviamente esprime meglio tutto, ma questo è ovvio.

La HE6 (non SE) è l'emulazione che solitamente tengo nel MorphIt, dopo un'estenuante serie di prove fra MI e PEQ ho scelto quel target e non lo cambio mai, anche con gli IEM.

Con il PEQ correggo leggermente i bassi e bassi estremi, ma non più di tanto.

-

È ovvio che succhi, è tutta classe A.

Non c'è niente da fare, il KA17 senza batteria supplementare non va bene... senza accendere tutta la BF un po' meno esigente, ma comunque consuma parecchio.

È la ragione per cui anche se ho questo mostro per quando sono in giro con gli IEM uso il Tanchjim, che comunque su driver a bassa impedenza suona benissimo senza scaricare il cellulare in mezz'ora.

Anche quello è un piccolo DAC USB che meriterebbe molta più attenzione, per il suo prezzo è un vero affare e quasi tutti hanno cuffie a bassa impedenza.

[Uncino]

@giuca70

Mi sono accorto di una cosa stranissima: il KA7 indica una velocità di flusso delle tracce HiRes doppia rispetto a quella indicata da Qobuz quando la riproduzione avviene attraverso l'applicazione originale, mentre la velocità indicata è quella corretta se si usa UAPP.

Chiaramente il DAC non può che scrivere la velocità di ciò che gli sta arrivando, quindi l'applicazione Qobuz esegue un sovracamponamento.

Te ne eri mai accorto?

[Uncino]

1 ora fa, Uncino ha scritto:

@giuca70

Mi sono accorto di una cosa stranissima: il KA7 indica una velocità di flusso delle tracce HiRes doppia rispetto a quella indicata da Qobuz quando la riproduzione avviene attraverso l'applicazione originale, mentre la velocità indicata è quella corretta se si usa UAPP.

Chiaramente il DAC non può che scrivere la velocità di ciò che gli sta arrivando, quindi l'applicazione Qobuz esegue un sovracamponamento.

Te ne eri mai accorto?

Mi sono accorto che anche l'applicazione Amazon Music fa lo stesso, ascolto un 24/192 e al DAC viene invitato un flusso 384.

[giuca70]

Si è normale per android.

Il sottoinsieme hardware senza UAPP viene "spinto" alla massima velocità disponibile del dac interno, nei suoi multipli più prossimi al 192 o 384. E' una funzione del s.o. android.

Uapp "prende" il controllo (tramite l'abilitazione di usb debug ON) del dac esterno direttamente e lo setta al valore corretto.

Per es. se UAPP con sotto Tidal sceglie un brano MQA viene mandato il corretto flusso, e cosi' anche per i flac fino a 192 KHz.

Se poi gli dai in pasto brani campione DSD, be'... è un pianeta a se'.

Già con Tidal ve benissimo uapp.

[Uncino]

18 minuti fa, giuca70 ha scritto:

Si è normale per android.

Il sottoinsieme hardware senza UAPP viene "spinto" alla massima velocità disponibile del dac interno, nei suoi multipli più prossimi al 192 o 384. E' una funzione del s.o. android.

Uapp "prende" il controllo (tramite l'abilitazione di usb debug ON) del dac esterno direttamente e lo setta al valore corretto.

Per es. se UAPP con sotto Tidal sceglie un brano MQA viene mandato il corretto flusso, e cosi' anche per i flac fino a 192 KHz.

Se poi gli dai in pasto brani campione DSD, be'... è un pianeta a se'.

Già con Tidal ve benissimo uapp.

No l'esatto contrario, evidentemente non mi sono spiegato bene.

 

UAPP manda al DAC il flusso originale, sono le applicazioni Qobuz ed Amazon Music a ricampionare al doppio.

UAPP su USB non usa i driver Android ma i suoi, esattamente come le applicazioni Qobuz ed Amazon Music.

E non gli serve la modalità Debug USB.

Boh, strana scelta delle due applicazioni delle due piattaforme, difficile dire se per ragioni di marketing o perché credono che effettivamente esista una qualche differenza sovracampionando, magari, un 192K... difficile.

 

[giuca70]

@Uncino  queste prove le ho ho fatte per mesi... le app native qobuz, ahd, tidal, non ottimizzano nulla. Sparano il flusso stream e stop. Poi il s.o. android ha il suo governor che fa come descritto nelle ultime release android.

Nella versione 14 per l'esattezza, rende disponibile le api (istruzioni particolari android) ai fornitori di app per gestire direttamente il flusso al dac esterno. Siamo agli inizi, fra qualche anno la app native saranno in grado di funzionare come uapp, oggi no.

Uapp è diverso, ha la sua gestione vincolata a requisiti hardware specifici, infatti non funziona con tutti i dispositivi android.

Dietro non c'è marketing, c'è solo un rincorrersi di standard e di funzioni del s.o. android.

Per il momento le app native apparentemente suonano meglio ( ma solo in apparenza) perche il dac esterno fa un sovracampionamento, ordinato dal dac interno (se ha specifiche superiori ai 48 KHZ), e se le cose funzionano in questi casi, sovracampionando esce un suono apparentemente migliore, ma se lo si confronta con il cosidetto bit perfect dentro uapp, non c'è storia. Alcuni DAC rivelatori ti fanno capire questo artefatto, e la cosa è davvero semplice.

Ne scrissi parecchio tempo fa.

Per es. su un tablet fascia alta che possiede un dac interno a 4 canali, con specifiche di campionamento fino ai 384 KHz, il sovracampionamento ordinato dal dac interno (a cui viene chiesto di settarsi al massimo della sua frequenza) è esattamente sempre 384 KHz. Qualsiasi dac esterno che accetti questa frequenza sovracampiona, e se non intervengono cadute o asincronie varie, il suono che si ascolta dalle app native apparentemente è migliore.

Ma c'è il disocorso volume assoluto, che con uapp è sempre al massimo se in bit perfect, anche col driver interno sul tablet.

Il tutto non è putroppo semplice da comprendersi subito, certamente se non si usa il corretto sincronismo del dac esterno, bypassando il dac interno e tutte le EQ a bordo android.

C'è stato un periodo in cui ritenevo le app native ed il sovracampionamento ottimi, per poi ricredermi quando settando per bene uapp, il confronto non regge essendo uapp spanne avanti nella gestione "corretta" del flusso binario verso il dac esterno, di cui ne detiene il massimo controllo, bypassando interamente il dac interno, anche quello del tablet da 384 KHz a 4 canali, ossia un quad dac specifico per Dolby Atmos. Mica un dacchetto da ridere.

 

[giuca70]

Poi un'altra cosa... qualcuno scrisse che il mac bypassa di default il dac interno. Non è sempre vero questo.

Anzi, per tutti i sistemi operativi di qualsiasi specie ordine e grado, sono tutti basati sul sistema binario e quindi su "livelli".

Tutte le piattaforme, linux, windows, apple, ios, andorid, ecc. sono basati su livelli.

Abbiamo l'hardware che deve avere a bordo alcune funzioni di suo (vedi il DAC, il controller usb, la cpu, GPU ecc).

Abbiamo il firmware che gestisce a livello macchina le fuonzioni sottostanti, cioè l'hardware sottostante.

Abbiamo il sistema operativo che gestisce il governor secondo funzioni imposte dalla release del s.o. (tutti i vari sistemi operativi) e quindi dispone al firmware le sequenze di funzionamento imposte dal governor del s.o.

Poi abbiamo le app ( i programmi ) che descrivono al s.o. come utilizzare le sue funzioni di governor.

Alcune app (vedi UAPP) hanno i loro driver riscritti per gestire meglio il firmware (il livello 2) bypassando il governor del s.o.

Questo decreta il successo di UAPP, i cui programmatori hanno "pensato" di creare un tunnel verso l'hardware riscrivendo i driver di molti chip DAC, non tutti e vincolando l'esecuzione ad alcune CPU che hanno istruzioni native sufficienti a gestire questo "tunnel", cioe' le snapdragon, piuttosto che i vecchi processori mediatek o ancora più scarsi.

Le CPU Intel, per inciso, possono eseguire in una sola istruzione migliaia di istruzioni maccihna rispetto quanto una CPU AMD deve fare. AMD è una emulazione di Intel, che detiene il primato.

La stessa cosa è per MAC con Intel, per Android con Snapdragon, ecc...

Quindi, le cose a livello intrinseco di specifcihe hardware, sono legate alla corretta gestione di UAPP per android.

Una cappella fatta per capire che quello che c'è dietro non è solo marketing... ma c'è un filone principale al quale si direbbe di comprare solo hardware già buono, prima di pensare alla app native dei fornitorei di streaming audio....

[Uncino]

3 ore fa, giuca70 ha scritto:

@Uncino  queste prove le ho ho fatte per mesi... le app native qobuz, ahd, tidal, non ottimizzano nulla. Sparano il flusso stream e stop. Poi il s.o. android ha il suo governor che fa come descritto nelle ultime release android.

Nella versione 14 per l'esattezza, rende disponibile le api (istruzioni particolari android) ai fornitori di app per gestire direttamente il flusso al dac esterno. Siamo agli inizi, fra qualche anno la app native saranno in grado di funzionare come uapp, oggi no.

Uapp è diverso, ha la sua gestione vincolata a requisiti hardware specifici, infatti non funziona con tutti i dispositivi android.

Dietro non c'è marketing, c'è solo un rincorrersi di standard e di funzioni del s.o. android.

Per il momento le app native apparentemente suonano meglio ( ma solo in apparenza) perche il dac esterno fa un sovracampionamento, ordinato dal dac interno (se ha specifiche superiori ai 48 KHZ), e se le cose funzionano in questi casi, sovracampionando esce un suono apparentemente migliore, ma se lo si confronta con il cosidetto bit perfect dentro uapp, non c'è storia. Alcuni DAC rivelatori ti fanno capire questo artefatto, e la cosa è davvero semplice.

Ne scrissi parecchio tempo fa.

Per es. su un tablet fascia alta che possiede un dac interno a 4 canali, con specifiche di campionamento fino ai 384 KHz, il sovracampionamento ordinato dal dac interno (a cui viene chiesto di settarsi al massimo della sua frequenza) è esattamente sempre 384 KHz. Qualsiasi dac esterno che accetti questa frequenza sovracampiona, e se non intervengono cadute o asincronie varie, il suono che si ascolta dalle app native apparentemente è migliore.

Ma c'è il disocorso volume assoluto, che con uapp è sempre al massimo se in bit perfect, anche col driver interno sul tablet.

Il tutto non è putroppo semplice da comprendersi subito, certamente se non si usa il corretto sincronismo del dac esterno, bypassando il dac interno e tutte le EQ a bordo android.

C'è stato un periodo in cui ritenevo le app native ed il sovracampionamento ottimi, per poi ricredermi quando settando per bene uapp, il confronto non regge essendo uapp spanne avanti nella gestione "corretta" del flusso binario verso il dac esterno, di cui ne detiene il massimo controllo, bypassando interamente il dac interno, anche quello del tablet da 384 KHz a 4 canali, ossia un quad dac specifico per Dolby Atmos. Mica un dacchetto da ridere.

Guarda tu stesso.

-

-

Ho pensato anche io che potesse dipendere da Android, ma non è così perché fa lo stesso sus sul Poco F4 GT (Android 14) che sul Lenovo Yoga Tab 13 (Android 13).

E buon può dipendere neppure dal KA17, altrimenti vedrei la stessa cosa quando il flusso gli viene inviato da UAPP.

Inoltre se a ricampionare 2X fosse il sistema operativo la cosa non sarebbe certo passata inosservata ma ne avremmo letto ovunque.

Questi software non utilizzano i servizi del sistema operativo, aprono la periferica USB e ci inviano un flusso.

UAPP, ripeto, trasferisce al DAC il flusso alla velocità indicata sulla traccia.

Non tengo abilitato il debug USB se non quando mi serve ed il Bit Perfect di UAPP è spento, perché se fosse acceso non potrei usare MorphIt e PEQ.

Non trovo nulla di complesso in ciò che hai scritto, dopo oltre quarant'anni passati nello sviluppo software riesco a seguire senza grandi difficoltà questi argomenti.

 

[Uncino]

3 ore fa, giuca70 ha scritto:

Poi un'altra cosa... qualcuno scrisse che il mac bypassa di default il dac interno. Non è sempre vero questo.

Anzi, per tutti i sistemi operativi di qualsiasi specie ordine e grado, sono tutti basati sul sistema binario e quindi su "livelli".

Tutte le piattaforme, linux, windows, apple, ios, andorid, ecc. sono basati su livelli.

Abbiamo l'hardware che deve avere a bordo alcune funzioni di suo (vedi il DAC, il controller usb, la cpu, GPU ecc).

Abbiamo il firmware che gestisce a livello macchina le fuonzioni sottostanti, cioè l'hardware sottostante.

Abbiamo il sistema operativo che gestisce il governor secondo funzioni imposte dalla release del s.o. (tutti i vari sistemi operativi) e quindi dispone al firmware le sequenze di funzionamento imposte dal governor del s.o.

Poi abbiamo le app ( i programmi ) che descrivono al s.o. come utilizzare le sue funzioni di governor.

Alcune app (vedi UAPP) hanno i loro driver riscritti per gestire meglio il firmware (il livello 2) bypassando il governor del s.o.

Questo decreta il successo di UAPP, i cui programmatori hanno "pensato" di creare un tunnel verso l'hardware riscrivendo i driver di molti chip DAC, non tutti e vincolando l'esecuzione ad alcune CPU che hanno istruzioni native sufficienti a gestire questo "tunnel", cioe' le snapdragon, piuttosto che i vecchi processori mediatek o ancora più scarsi.

Le CPU Intel, per inciso, possono eseguire in una sola istruzione migliaia di istruzioni maccihna rispetto quanto una CPU AMD deve fare. AMD è una emulazione di Intel, che detiene il primato.

La stessa cosa è per MAC con Intel, per Android con Snapdragon, ecc...

Quindi, le cose a livello intrinseco di specifcihe hardware, sono legate alla corretta gestione di UAPP per android.

Una cappella fatta per capire che quello che c'è dietro non è solo marketing... ma c'è un filone principale al quale si direbbe di comprare solo hardware già buono, prima di pensare alla app native dei fornitorei di streaming audio....

Non conosco l'ambiente Apple, ma si può fare la stessa cosa su qualsiasi sistema operativo che consenta a processi che vengono eseguiti con privilegi ordinari di aprire /dev/ttyUSBx (o nome equivalente).

 

[Uncino]

@giuca70

Non ho mai sviluppato per Android, ma come immaginavo esso consente la gestione delle periferiche USB da parte di applicazioni eseguite con privilegi utente.

Da una semplice ricerca sono emersi moltissimi riferimenti e librerie, ad esempio questa su GitHub.

Quindi bypassare il sistema operativo è banale, come dicevo è sufficiente fare una open verso la porta e poi inviarvi il flusso di dati.

Immagino che lo stesso valga per i sistemi operativi Apple.

[giuca70]

Concordo, quindi potrebbe essere una furbata relativa alle ultime release android..

Cio' spiegherebbe perche' alcuni sostengono di sentire meglio le app native...

Abbiamo lo stesso tablet.

Il Poco è una bestia !! Complimenti ho letto le specifiche.

Se gsmarena dice la verità il suo dac interno è 24/196

.

.

Quindi, il flusso aperto verso la usb si "fionda" al massimo 384 KHz...

In effetti con android 12 le cose non stanno cosi', e con altri smartphone vecchiotti il limite è sempre 48 KHz... ricordo, ma ora che m icia hai messo la pulce, verifico se è l'app a fare qualcosa di nuovo...

Tempo di caricare il vecchio Galaxy

 

[Uncino]

16 minuti fa, giuca70 ha scritto:

Concordo, quindi potrebbe essere una furbata relativa alle ultime release android..

Cio' spiegherebbe perche' alcuni sostengono di sentire meglio le app native...

Abbiamo lo stesso tablet.

Il Poco è una bestia !! Complimenti ho letto le specifiche.

Se gsmarena dice la verità il suo dac interno è 24/196

.

.

Quindi, il flusso aperto verso la usb si "fionda" al massimo 384 KHz...

In effetti con android 12 le cose non stanno cosi', e con altri smartphone vecchiotti il limite è sempre 48 KHz... ricordo, ma ora che m icia hai messo la pulce, verifico se è l'app a fare qualcosa di nuovo...

Tempo di caricare il vecchio Galaxy

Il Lenovo Yoga Tab 13 è semplicemente fantastico, un vero peccato che nonostante il costo non certo basso, Lenovo gli dedichi così poca attenzione.

Quanto al Poco, è il mio primo telefono con MIUI, e già un paio di giorni dopo averlo comprato avevo deciso che anche il successivo sarebbe stato uno Xiaomi Poco di fascia alta.

Il suo DAC interno gestito da UAPP è quasi al livello dei dongle USB... su questo telefono Xiaomi proprio non è andata al risparmio!

Funzionano magnificamente anche i processori di segnale bundled, sia quello Xiaomi che il Dolby Atmos.

E che dire dei 4 speaker... na figata.

Ha alcune idiosincrasie, ad esempio non c'è modo di fargli smettere di disabilitare i permessi di accessibilità dopo un periodo di inutilizzo (leggi, di notte), cosa che crea casini con applicazioni che ne hanno bisogno, ma ho risolto con una semplice routine Auromate che li riabilita.

Auromate dovrebbe essere fornito con ogni telefono perché cambia completamente la vita su Android!

-

Sul tablet Lenovo vedrai che lo fa anche a te, visto che me ne sono accorto con quello.