Gustard R30 streamer DAC

[Steph44200]

Salut

Le R30 demande bien une centaine d’heures avant de s’exprimer pleinement
En le plaçant en standby entre deux utilisations

[Olivier]

Disons que mon expérience m'a montré, qu'avec un dac, s'il n'y a pas de signaux de potentiels dans les premières heures ou jours (max 2 ou 3), faut pas s'attendre à de grandes révolutions à 300 ou 400 heures. Je ne renie pas des petites améliorations, mais je suspecte plus une accoutumance auditive.

L'idée étant d'avoir mieux que la proposition du dac intégré à mon ampli. Celui ci est, et c'est plutôt une exception, tout sauf accessoire, et se situe dans la production actuel inférieur à 2000€. Malgré son aspect technique simple et sa limite à 24/192, son intégration est réussi et je pourrai vivre avec. Le X30 m'a bien plu dans ce système, mais s'il proposait tout en un peu mieux, le gap n'était pas assez important pour l'investissement et l'ajout d'un élément dans le meuble. PER (Per Earning Ratio) trop faible à mon goût, malgré le comportement d'excellent petit classe A avec des capacités qui semblent illimitées (dixit le concepteur, dont je modèrerai l'enthousiasme) de mon ampli. La proposition de ce superbe DAC reste encore sur mon système trop "vrai" et pas assez "belle" (dédicace à notre ami Nicoben). Sans en faire la liste exhaustive, j'ai essayé d'autres propositions, toutes de très bonne facture, avec pour conclusion et pour résumer: "trouver un hybride entre un excellent delta sigma et un très bon R2R". 
Le R30 représente un peu le DAC de la dernière chance, avant d'envisager d'autres matériels aux conséquences financières.... dramatiques, et ce même en seconde main !

J'ai vite zappé le streamer interne qui de mon point de vue limite les performances du DAC. Mon streamer Shanling SMT1.3 dispose d'une sortie I2S paramétrable et le mode 7 sur celui ci, correspond exactement à l'entrée I2S "G" du R30. Cela me permet aussi d'apprécier, à la volée, l'upsample jusqu'au DSD512.

[lotofoot46]

Bonjour
Merci Olivier
Bon rodage et bonne écoute.

[Nagual]

Laisse lui un 20h allumé déjà,
Histoire que tout se stabilise.
Après je suis comme toi si en 2/3j c’est pas au niveau ça changera presque plus.
Avec l horloge il sort un grave de l espace !
Et même sans il est loin d être ridicule
Enjoy

[Olivier]

Je n'ai pas besoin d'horloge en I2S !
Je vais suivre ton conseil de laisser allumé quelques jours, mais en utilisant le réglage de Kiki et en lui envoyant du DSD, il se passe quelque chose de très intéressant !

[Matamboy]

L'horloge du Shanling est meillieur que celle du R30 ? Tu utilises celle SMT1.3 en I2S ?

[Olivier]

Je pense que les horloges doivent être du même niveau de performance. Par contre, je ne sais pas qu'elle est la maître. Je fais l'hypothèse que le R30 garde son horloge en I2S.

[Matamboy]

Kiki est demandé

[Granitor]

Il me semble qu'en principe, en IIS , c'est l'horloge de l'interface qui prend la main , et que donc, si sur cette interface , on connecte une horloge externe, alors c'est elle qui prend la main.

[Olivier]

Voici ce que dit Copilot :

En I²S, l’horloge maîtresse est presque toujours fournie par la source — donc dans ton cas, le streamer.
Voici le fonctionnement détaillé :

---

Les 3 signaux (ou 4) d’une liaison I²S
Une liaison I²S transporte généralement :

1. BCLK (Bit Clock) – rythme le flux de bits audio
   
2. LRCLK / WS (Left Right Clock / Word Select) – indique canal gauche ou droit
   
3. DATA – les données audio
   
4. MCLK (Master Clock) – parfois utilisé selon les DACs
   

---

Qui génère l'horloge ?
✅ En usage normal : c’est le streamer (la source)
Dans une architecture classique :

• Le streamer génère BCLK, LRCLK, et parfois MCLK
  
• Le DAC est esclave, c’est‑à‑dire qu’il se cale sur ces horloges
  

➡️ Donc le DAC ne génère pas l’horloge, il la reçoit.

---

Pourquoi la source doit-elle être maître ?
Parce que l’I²S est conçu comme une interface source → esclave, contrairement au SPDIF où le DAC récupère l’horloge encodée.
I²S ne transporte aucune horloge récupérable : elle doit obligatoirement être fournie séparément.

---

Exception : certains DAC peuvent être maîtres
Certains DAC haut de gamme (ex : ESS avec mode “asynchronous I²S”) permettent :

• DAC → génère MCLK et BCLK
  
• Streamer → devient esclave et envoie seulement DATA et LRCLK
  

Mais cela nécessite un matériel conçu pour ça des deux côtés, ce qui reste rare.

---

Résumé
Signal
Généré par
RôleBCLK
Streamer (90% des cas)
Cadence les bits
LRCLK/WS
Streamer
Sépare gauche/droite
DATA
Streamer
Audio numérique
MCLK
Streamer (ou DAC dans rares cas)
Horloge maître interne du DAC

---

Et Mistral:
Dans une liaison **I2S** (Inter-IC Sound) entre un streamer (source numérique) et un DAC (convertisseur numérique-analogique), **l'horloge (ou signal d'horloge, souvent noté BCLK ou SCK)** est généralement **fournie par le maître de la liaison I2S**.

### Qui est le maître dans une liaison I2S ?
- **Le streamer** (ou la source numérique, comme un Raspberry Pi, un DAC externe, ou un streamer audio dédié) agit généralement comme **maître** et fournit les signaux d'horloge (BCLK) et de synchronisation (LRCLK ou WS).
- **Le DAC** agit alors comme **esclave** et se synchronise sur l'horloge fournie par le maître.

### Pourquoi cette configuration ?
- Cela permet d'éviter les problèmes de synchronisation (jitter) entre les deux appareils.
- Le DAC esclave utilise l'horloge du maître pour échantillonner les données audio de manière synchronisée.

### Exceptions et cas particuliers
- Certains DAC haut de gamme ou systèmes audio peuvent **générer leur propre horloge** et imposer au streamer de s'y synchroniser (mode "maître" pour le DAC). Cela dépend de la conception du matériel et des réglages disponibles.
- Dans les systèmes asynchrones (comme certains DAC USB), le DAC peut utiliser une horloge interne ultra-précise et demander à la source de s'adapter via un mécanisme de rééchantillonnage.

### En résumé
Dans la plupart des cas, **c'est le streamer qui fournit l'horloge** (mode maître) et le DAC la suit (mode esclave).