Citation de ThierryNK le 4 septembre 2021, 12:34

LOL!!

Je n'ai jamais dit que le lecteur de Roon était une bouse!! Je n'en sais rien.

Je donne juste des pistes pour expliquer des différences, pistes qui sont très "sérieuses". Mais après, les différences perçues par les uns ou les autres sont peut être dûes à radicalement autre chose, je n'en sais rien.

Ce dont je suis certain par contre c'est que décoder une piste audio est beaucoup moins anodin que ce qu'on imagine.

Extraire des échantillons DATA, OK. Récupérer un signal d'horloge OK. Envoyer le tout simultanément et de manière cohérence au DAC, cela devient sérieusement complexe.

Quand on utilise des buffers (des mémoires tampon) pour les data avant envoi, la simple latence et la taille des buffers peut foutre un boxon gigantesque.

Et pourtant les buffers sont indispensables pour éviter les coupures.

Mais tu te retrouves à devoir gérer l'extraction de données d'un buffer avec alignement temporel avec une horloge précise à au moins 10^-9s. Buffer trop petit: coupures. Buffer trop grand: latences en augmentation. C'est tout sauf élémentaire à régler.

Les fabricants de drives spdif/AES ou de lecteurs réseau intégrés, ont l'avantage d'avoir la main sur tout: entrée réseau, processeur ou FPGA, mémoire, buffers, horloges, circuits, isolations.

 

Différences minimes de ton côté entre quoi et quoi?

 

Citation de filidan-pda0 le 4 septembre 2021, 12:39

Citation de ThierryNK le 4 septembre 2021, 12:03

@filidan-pda0

Je ne sais pas si Roon est moins bon, je n'ai jamais utilisé et jamais fait de comparaisons.

Tu cherchais des pistes pour expliquer des différences, je t'en ai fourni de sérieuses.

Je pense contrairement à toi que c'est par paresse/facilité qu'il n'y a que Roon dans le Tambaqui, parce que c'était une boite noire à implémenter, alors qu'il fallait effectuer un développement pour UPNP (je te rappelle que les bugs liés au DSD ne sont toujours pas corrigés, et qu'il y a d'abord eu déni pour finalement dire du bout des lèvres "ah oui")

Pour la partie que tu appelles "Logiciel qui crée le flux", je pense que tu es dans l'erreur. Il ne s'agit pas que d'un logiciel, mais de la création d'un flux audio temps réel avec un signal d'horloge.

Comment d'horloge du Tambaqui est utilisée par Roon? On n'en sait rien!!! Comment Roon gère-t-il des signaux d'horloge radicalement différents en fonction des matériels avec la même boite noire fournie à tous les fabricants? On n'en sait rien non plus!

Si ce que tu dis était vrai, la Chromecast, isolée électriquement par fibre optique serait exactement équivalente à un Auralic ou à un Amethyst, et ce n'est pas vraiment le cas. En bonne logique, pour démontrer qu'une proposition est fausse, il suffit d'un seul contre exemple.

Enfin, dans un matériel à 10k€, j'attends du sur mesure et pas de la boite noire.

Bises

Pour le Tambaqui, tu fais l'hypothèse qu'ils sont fainéants et pas très bons, mais c'est une hypothèse pas une démonstration. Quand on voit le soin qu'ils ont apporté à la conversion et à la gestion de l'horloge justement, pourquoi auraient-ils négligé la partie réseau au point de dégrader leur produit DAC phare ? Si c'est le cas, ils sont vraiment nuls, mais permets moi d'en douter.

Pour la différence entre la Chromecast et le reste, je ne vois pas le rapport. L'alimentation de la Chromecast est minimaliste, on ne sait rien de la qualité de son horloge pour créer le flux SPDIF, et on ne sait rien de la réception fibre optique qui peut aussi avoir ses problèmes propres. La différence entre Auralic et Amethyst est à mon avis, plus dans la gestion électrique du bousin (et sans doute la qualité des horloges) , que dans la partie création du flux qui doit être assez normalisée (ça m'étonnerait qu'il n'existe pas de logiciel source type pour ce genre de conversion que tout le monde fait depuis la création du CD).

Citation de filidan-pda0 le 4 septembre 2021, 12:42

Citation de ThierryNK le 4 septembre 2021, 12:34

LOL!!

Je n'ai jamais dit que le lecteur de Roon était une bouse!! Je n'en sais rien.

Je donne juste des pistes pour expliquer des différences, pistes qui sont très "sérieuses". Mais après, les différences perçues par les uns ou les autres sont peut être dûes à radicalement autre chose, je n'en sais rien.

Ce dont je suis certain par contre c'est que décoder une piste audio est beaucoup moins anodin que ce qu'on imagine.

Extraire des échantillons DATA, OK. Récupérer un signal d'horloge OK. Envoyer le tout simultanément et de manière cohérence au DAC, cela devient sérieusement complexe.

Quand on utilise des buffers (des mémoires tampon) pour les data avant envoi, la simple latence et la taille des buffers peut foutre un boxon gigantesque.

Et pourtant les buffers sont indispensables pour éviter les coupures.

Mais tu te retrouves à devoir gérer l'extraction de données d'un buffer avec alignement temporel avec une horloge précise à au moins 10^-9s. Buffer trop petit: coupures. Buffer trop grand: latences en augmentation. C'est tout sauf élémentaire à régler.

Les fabricants de drives spdif/AES ou de lecteurs réseau intégrés, ont l'avantage d'avoir la main sur tout: entrée réseau, processeur ou FPGA, mémoire, buffers, horloges, circuits, isolations.

 

Différences minimes de ton côté entre quoi et quoi?

 

Différences minimes (si existantes) entre Roon, JRiver et Audirvana en UPnP et/ou USB, et encore entre Raat et Diretta (dans mon setup minimaliste Diretta bien entendu).

Mola Mola aussi a la main sur l'entrée réseau, FPGA, buffers, horloges, isolation, etc... et l'avantage d'un circuit ultra-court et aucune dépendance sur les câbles 😉

Citation de ThierryNK le 4 septembre 2021, 12:44

Oui, c'est une hypothèse. Mais il n'y a strictement rien à voir entre la conception d'un DAC, aussi génial et innovant soit-il et l'écriture d'un logiciel de lecture de piste.

Pour le reste, c'est toi qui a écrit que tous les problèmes venaient des alimentations:

Je suis aussi persuadé que la principale différence entre le streamer de l’Amethyst et ton nouvel Auralic est liée à la gestion du bruit (alims etc…) et au hardware PC « antique » de l’Amethyst, plutôt qu’à la partie logicielle qui crée le flux AES. 

Auralic et Chromecast sont en fibre optique, strictement aucune influence électrique!!!!

Ce sont donc bien horloge et évidemment en liaison directe avec le logiciel de lecture qui jouent. Non mais!!! ?

 

Mola Mola n'a PAS la main sur le logiciel de lecture et son intégration avec l'horloge.

Citation de ThierryNK le 4 septembre 2021, 12:49

PS: quand on arrive à se prendre les pieds dans le tapis pour reconnaître les données d'entête d'un DoP, qu'on commence par nier, et qu'on ne corrige pas un an après, c'est peut-être (hypothèse) que l'informatique, même pas temps réel, ne fait pas partie des gènes de l'entreprise.

Citation de Nobody le 4 septembre 2021, 13:22

Citation de Gordian le 4 septembre 2021, 09:20

Salut @thierrynk

Ma réflexion était plus au niveau des protocoles utilisés. Point de théorie de mon coté, juste un fauteuil et des oreilles au dessus, c'est mon instrument de mesure. 

 Avec Patatorz, nous avons testé sur les même appareils (je ne sais plus lesquels) qui étaient compatibles UPNP, LMS et Roon. Roon était dans tous les cas le bon perdant avec un bon gap, à tel point que je pense que même un UPNP en AES sera supérieur au Roon intégré au gros poisson.  

 

Metrum Ambre et 3dlab Nano dernière génération 

Citation de ThierryNK le 4 septembre 2021, 13:34

Citation de Patatorz le 4 septembre 2021, 13:22

Citation de Gordian le 4 septembre 2021, 09:20

Salut @thierrynk

Ma réflexion était plus au niveau des protocoles utilisés. Point de théorie de mon coté, juste un fauteuil et des oreilles au dessus, c'est mon instrument de mesure. 

 Avec Patatorz, nous avons testé sur les même appareils (je ne sais plus lesquels) qui étaient compatibles UPNP, LMS et Roon. Roon était dans tous les cas le bon perdant avec un bon gap, à tel point que je pense que même un UPNP en AES sera supérieur au Roon intégré au gros poisson.  

 

Metrum Ambre et 3dlab Nano dernière génération 

Tu peux parfaitement citer ton BE, intéressant et documenté au demeurant, du Metrum:https://patatorz.com/2018/08/31/metrum-acoustics-ambre-un-lecteur-reseau-attachant-a-plus-dun-titre/

Tu peux aussi ouvrir un fil dédié à son sujet.

Amicalement

Citation de Nobody le 4 septembre 2021, 13:37

 

Pour quelqu'un qui vient d'affirmer qu'il y a forcément un lien entre filtrage et drive, c'est un poil olé olé, non? ?

Smac ?

Bonjour, pas facile de se faire comprendre, je ne maîtrise pas l’art de la communication.

Il faut se remettre dans le contexte du produit : l’aries. Ce dernier intègre des filtres. S’ils sont là c’est pour répondre à un besoin du client ou un cahier des charges marketing. On aime ou on aime pas c’est pas le problème. Je regrette juste que quand je l’ai écouté la restitution sans filtre était plus que perfectible et qu’il fallait y ajouter des filtres pour y retrouver un intérêt. C’est mon constat sur ce drive.

Pour ma part j’ai tout dit et tant pis si je ne suis pas compris.

Gros Poutou

Citation de ThierryNK le 4 septembre 2021, 13:54

Je trouve que tu te débouilles très bien en comm, je lis ton blog...

J'ai compris que l'Auralic ne t'avait pas plu du tout. OK.

En essayant d'être rationnel...

L'utilisation de filtres (qui ne sont là que comme "commodité") pour "améliorer" les choses, cela relève de la balance tonale ou de la correction d'un accident de réponse dû à la pièce. Dans les deux cas, c'est une correction ou de la pièce ou des enceintes ou du DAC, éventuellement d'un spdif sur RCA, mais pas du drive en tant que tel.

On a assez rarement vu un signal spdif ou AES traité différemment suivant la bande de fréquence (sauf spdif sur RCA)

Sur Metrum, DCS et Auralic, il y a des horloges correctes et un logiciel de décodage correct. Quand les drives semblent avoir des effets sur la balance tonale, il me semble, à la fois théoriquement et par expérience, qu'il faut chercher les raisons ailleurs que dans le drive.

Bisous aussi ?

Citation de Gordian le 4 septembre 2021, 14:13

ben dis donc, ca se bisouille de partout ici 😎 

Excusez-moi avec le Covid, j'en fais moins 🙂  

Petite question niveau technique ; je sais que pour le DSD on se doit de passer par des filtres qui font un tas de choses super essentielles mais quid du PCM ? L'application de filtre est-elle nécessaire ou peut-on s'en affranchir ? Si oui, pourquoi en mettre alors qu'on s'évertue à faire du fil droit partout ailleurs ?

 

Citation de ThierryNK le 4 septembre 2021, 14:45

Dans une pièce de taille standard, il est strictement impossible d'avoir une réponse "droite" dans les basses. Nous avons tous des bosses plus ou énormes entre 30 et 50 Hz qui sont liées à la géométrie de la pièce.

Equalisation à 35 Hz en ce qui me concerne:

 

Réponse mesurée avec et sans équalisation

 

 

Citation de filidan-pda0 le 4 septembre 2021, 14:46

Citation de ThierryNK le 4 septembre 2021, 12:44

Oui, c'est une hypothèse. Mais il n'y a strictement rien à voir entre la conception d'un DAC, aussi génial et innovant soit-il et l'écriture d'un logiciel de lecture de piste.

Pour le reste, c'est toi qui a écrit que tous les problèmes venaient des alimentations:

Je suis aussi persuadé que la principale différence entre le streamer de l’Amethyst et ton nouvel Auralic est liée à la gestion du bruit (alims etc…) et au hardware PC « antique » de l’Amethyst, plutôt qu’à la partie logicielle qui crée le flux AES. 

Auralic et Chromecast sont en fibre optique, strictement aucune influence électrique!!!!

Ce sont donc bien horloge et évidemment en liaison directe avec le logiciel de lecture qui jouent. Non mais!!! ?

 

Mola Mola n'a PAS la main sur le logiciel de lecture et son intégration avec l'horloge.

A la réflexion, j'avoue que je ne comprends pas le lien que tu fais entre Roon et la création du flux temps réel qui va être converti dans le DAC. En fait, je ne vois pas pourquoi Roon serait impliqué là dedans à vrai dire. Roon envoie le fichier avec le protocole Raat, le Tambaqui intègre un module Roon ready qui récupère le fichier en décodant le protocole Raat, puis se débrouille avec ensuite, comme lorsqu'il reçoit le même fichier en USB par exemple, ou comme il ferait s'il recevait un fichier en UPnP.

Je ne vois pas bien pourquoi il y aurait plusieurs protocoles de création de ce flux avant la conversion propriétaire de Putzeys d'ailleurs suivant comment arrivent les données.

Si je me réfère à ce qu'en disent ce qui on regardé comment c'était fait : 

"The DAC architecture is described by the company as a ‘two board stack, in which all incoming data is upsampled to 3.125MHz/32-bit and converted to noise- shaped PWM on the first board, and then handled by two mono DACs on the second board’. Mola-Mola has its own, custom DAC solution executed in DSP. There are no off-the-shelf DAC chips inside the Tambaqui... Mola-Mola’s software upsamples all incoming data to 3.125MHz, truncating the word length to 5-bits while using a 7th-order noise-shaper to retain full dynamic range right up to 80kHz. Each 5-bit digital ‘word’ is sufficient to describe one of 32 possible pulse widths that, in turn, describe the amplitude of the audio signal on an (over)sample-by-sample basis. The pulses vary in steps of 10nsec (the system clock is 100MHz) right up to a full width of 320nsec (0.32μsec). This Pulse Width Modulated (PWM) signal is fed into a 32-stage shift register, clocked at 100MHz, so a composite of 32 pulses ends up reproducing the full PWM signal every 10nsec.

The 32 outputs of the register are summed together so that the final DAC output is the moving average of the PWM signal over consecutive blocks of 32 clock cycles (ie, one PWM cycle), updating every 10nsec. The PWM signal is ‘conditioned’ by a comb filter whose teeth coincide exactly with the 3.125MHz repetition rate. Mola-Mola could have used the signal from any of the 32 outputs alone and simply low-pass filtered it. Instead, the moving average technique not only overcomes any slight mis-match in the summing resistors but it also removes the PWM carrier that could potentially demodulate clock jitter down into the audio band."

Je ne vois pas bien en quoi le petit module de récupération des données (qu'il soit Raat, UPnP ou USB) aurait la moindre influence sur ce qui se passe ensuite dans la conversion qui se doit être en temps réel. Entre les deux, réception des données, et conversion temps réel, il y a la place pour un bon buffer qui peut s'occuper d'éviter les "trous". Si on débranche l'entrée RJ45 du Tambaqui, il continue d'ailleurs à jouer pendant 7 secondes, donc il y a au moins un buffer de 7 secondes (indépendant d'ailleurs du débit des données car ce temps est le même en DSD128 et en 16/44).

Bon, je ne suis pas un spécialiste du sujet, mais j'espère que les gars qui sont capables de concevoir un DAC innovant comme celui du Tambaqui, doivent avoir quelques notions de création d'un flux temps réel pour faire ladite conversion, même s'ils sont fainéants au point de ne pas avoir mis de module UPnP....

Citation de ThierryNK le 4 septembre 2021, 14:49

En USB on ne reçoit pas de fichier.

Que se passe-t-il entre le fichier RAAT et l'étage suivant, je n'en sais rien.

En tous cas, il ne peut y avoir aucune analogie ni approche identique entre USB et l'arrivée d'un fichier.

Citation de filidan-pda0 le 4 septembre 2021, 14:59

Et en USB tu reçois quoi si c'est pas un fichier ? Dans ma vue simpliste du sujet, je vois le problème à résoudre comme l'envoi d'un fichier par petits bouts (car on envoie par petits paquets que ce soit en USB ou en ethernet) qu'on doit ensuite convertir en signal analogique, ce qui nécessite une horloge à un moment donné. USB et ethernet n'envoient pas d'horloge, contrairement à SPDIF et AES. Ce qui se passe ensuite dans le DAC est le savoir-faire du fabricant. Que fait-on du signal d'horloge qui arrive en SPDIF ou AES ? Comment intègre-t-on une horloge pour la conversion et à quel moment ça devient du temps réel, je ne sais pas, mais pour revenir au sujet Raat ou UPnP, j'avoue avoir beaucoup de mal à imaginer que ça puisse faire la moindre différence une fois que les données sont arrivées à bon port...

Diretta, par exemple, découpe le fichier en plein de tous petits paquets afin d'éviter les à-coups sur l'alimentation et plans de masse (si j'ai bien compris) et donc cherche à réduire le bruit environnant, mais ça n'implique rien, a priori, sur la suite du process temps réel dans le DAC, qui va devoir se débrouiller avec les données reçues et faire sa propre cuisine.

Citation de ThierryNK le 4 septembre 2021, 15:17

En USB on reçoit un flux de données temps réel et non un fichier, flux cadencé par l'horloge du DAC ou de l'ordinateur ou des deux.

Peut être se renseigner au sujet des protocoles USB 😉  j'ai l'impression une nouvelle fois d'être revenu 15 ans en arrière. 

Les questions de buffers en USB se posent de la même façon qu'expliqué précédemment.

En spdif et Aes, le lien data-horloge est intégré dans le signal. Mieux en AES qu'en spdif.

Ce qui se passe après l'entrée spdif ou aes dans le Tambaqui est parfaitement clair. Les horloges du drive et du DAC sont déterminantes.

En USB, c'est à peu près clair, mais pas totalement. 

Ce qui se passe avec Roon, je n'en sais strictement rien.

Bises non Covidiennes 

Citation de filidan-pda0 le 4 septembre 2021, 16:39

Et sais-tu ce qu’il se passe en UPnP ? Il est fort probable que ce soit pareil avec Roon Raat 😉

Citation de ThierryNK le 4 septembre 2021, 17:02

SCOOP

Il n'y a pas d'UPNP sur Tambaqui, alors pour dire que c'est pareil que RAAT, je m'abstiens 😉 

Sinon, sur quel appareil ?

Pour les Ayon, 3DLab, Chord, Lumin notamment, oui, c'est suffisamment documenté pour savoir comment c'est fait, plus des documents NDA fournis par certains fabricants.

Bon, le maire est arrivé ?

Citation de filidan-pda0 le 4 septembre 2021, 17:34

Je sais qu’il n’y a pas UPnP sur le Tambaqui 🙂

Mais c’est un protocole réseau comme UPnP et donc une fois les données arrivées, il y a bien un process de traitement qui doit se ressembler un peu dans toutes les machines. 
Devialet, qui n’est pas connu pour avoir les meilleurs programmeurs du monde 😯 , a mis en oeuvre UPnP, Raat et Devialet Air qui sont 3 protocoles de transfert de données sur réseau, et je doute que le process qui suit soit totalement différent suivant que les données arrivent en UPnP, Raat ou Air. 

Ce ne sont certes que des suppositions mais plutôt plausibles quand on fait du développement logiciel, et pas plus improbables que d’imaginer que Raat fait n’importe quoi parce qu’on ne sait pas ce qu’il fait et que UPnP c’est mieux parce qu’on sait ce qu’il fait. 

Bises au maire 🙂

Citation de ThierryNK le 4 septembre 2021, 20:55

C'est marrant ce dialogue de sourds.

S'il y a qq chose de complexe, ce n'est ni RAAT ni UPNP.

C'est le logiciel temps réel qui couple horloge et data.

Dans de nombreux matériels, on sait ce qui est fait à partir de la piste, qu'elle arrive par UPNP, RAAT ou le Saint Esprit. On s'en fout de la manière dont le fichier arrive.

Si le module RAAT se borne à de la gestion de fichiers et la télécommande d'un lecteur implémenté par le fabricant, alors cela prend 20 bonnes minutes d'implémenter upnp. 

Et c'est le cas de l'upnp !!! Il ne s'occupe pas d'audio !! 

Si RAAT  prend aussi en charge le transfert data horloge, on est au delà d'un logiciel de pilotage. On est dans l'un des cœurs de métier de l'audio. 

Pour Info, Air était un flux temps réel, comme USB, et pas un transfert de fichier.

J'ai fait la bise au maire de ta part.