Raul1 ha scritto:
ma sul teac si
Eddaje...
Roon Server è un'applicazione che può girare su Mac/Linux/Windows.
Su
linux e su
macOS non servono driver per
nessun DAC e nessuna applicazione, quindi se Roon è installato in uno di questi sistemi operativi non ha bisogno di nulla per comunicare con il dac.
Questo vale per tutti i DAC di recente manifattura.
Il
Teac ha bisogno di driver
solo se collegato ad un PC che ha installato windows.
Infatti se vai sul sito della
Teac trovi driver solo per questo sistema operativo
http://www.
teac.com/product/
ud-503/downloads/
Quindi se usi Roon Server su windows potresti aver bisogno di driver.
Nel caso che abbiamo descritto sopra siamo in uno scenario ancora diverso: endpoint che passa via USB i dati al DAC esterno.
Qui gli scenari sono tre:
1) sia
Auralic che
Cocktail passano quei dati in maniera "sbagliata" e al
Teac questa cosa non piace
2) il parsing di questi formati non è stato implementato a regola d'arte dalla casa nipponica e quindi quel flusso non viene decodificato sempre agilmente
3) Roon ha un bug in questo ambito
Il fatto che
SoTM (che è un endpoint come gli altri due) funzioni a questo punto potrebbe tagliar fuori
Teac e RoonLabs come colpevoli...
Ma
Auralic passa senza problemi quella frequenza al Burson, quindi questo fa ricadere i riflettori sul
Teac... In sostanza... Non saprei
Dubito fortemente che la questione verrà risolta a breve perché quel formato non è diffuso commercialmente quanto un DSD64 o un banale 24/192...
Dovremo aspettare che venga riconosciuto da qualcuno degli attori (Roon Labs?
Teac? Auralic? CA?) come bug proprietario.