Le Forum Indépendant de la Hifi et des Audiophiles

Version complète : C'est quoi pour vous un pc audiophile
Vous consultez actuellement la version basse qualité d’un document. Voir la version complète avec le bon formatage.
Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
Tu abandonnes Mac et deviens linuxien ?  Tongue   Je suis content pour toi que ça marche ! Smile

Honnêtement je ne vais pas dire que Linux est supérieur à OSX, mais le fait que Linux est libre permet au communauté de développeurs de créer des systèmes minimalistes dédiés à l'audio, chose qu'on arrive pas à faire avec OSX ou Windows.
Et piCorePlayer ou Daphile ... existe depuis déjà pas mal de temps.
.Mode troll [on]:

"Devenir linuxien"... N'abusons pas, il ne s'agit que de copier un OS sur une clé USB et de booter dessus !

On devient "linuxien" quand on sait installer et administrer une LFS, Gentoo, ArchLinux, recompiler son noyau par exemple mais là, honnêtement... Smile

.Mode troll [exit 0]
Bonjour,

Effectivement, je rejoins l'avis de Morbius. Aujourd'hui n'importe quel PC permet d'envoyer des fichiers vers un DAC, ou une carte son, sans *aucune* perte, ni probleme de latence quelconque.

Même du coté des DACs ou la transmission est effectuée via l'USB, le protocole utilisé permet au recepteur de controler son buffer en signalant à l'envoyeur quand il doit/peut emettre.
Il faut savoir qu'avec ce protocole, il ne peut y avoir qu'un seul cas d'erreur audible: L'emmeteur n'envoie pas assez vite, et les buffers du recepteurs sont vides, ou un paquet de donnée est incorrect (contrôle par CRC), auquel cas, il est simplement rejeté sans être redemandé (le protocole ne le permet pas).
Lorsque de tels phenomenes arrivent, on peut entendre soit un trou dans le son, soit le recepteur rejoue ses anciens buffers (ce qui est souvent le cas sur les DACs), soit, plus rare, on entends un souffle assez fort dans la gamme des medium haut (8Khz pour être précis)

A partir du moment ou le processeur du PC n'est pas occupé à 100%, peu de chance que ça arrive.
De la même façon, le parasitage electrique de l'USB est rare (bien plus qu'on pourrait le penser) et son influence est souvent marginale et inaudible.

En bref, un simple PC portable avec n'importe quel OS suffit pour faire un "PC Audiophile" (là je sens que je vais m'attirer les foudres des puristes Smile )
(03-07-2016, 12:16 AM)Bkg2k a écrit : [ -> ]Bonjour,

Effectivement, je rejoins l'avis de Morbius. Aujourd'hui n'importe quel PC permet d'envoyer des fichiers vers un DAC, ou une carte son, sans *aucune* perte, ni probleme de latence quelconque.

Même du coté des DACs ou la transmission est effectuée via l'USB, le protocole utilisé permet au recepteur de controler son buffer en signalant à l'envoyeur quand il doit/peut emettre.
Il faut savoir qu'avec ce protocole, il ne peut y avoir qu'un seul cas d'erreur audible: L'emmeteur n'envoie pas assez vite, et les buffers du recepteurs sont vides, ou un paquet de donnée est incorrect (contrôle par CRC), auquel cas, il est simplement rejeté sans être redemandé (le protocole ne le permet pas).
Lorsque de tels phenomenes arrivent, on peut entendre soit un trou dans le son, soit le recepteur rejoue ses anciens buffers (ce qui est souvent le cas sur les DACs), soit, plus rare, on entends un souffle assez fort dans la gamme des medium haut (8Khz pour être précis)

A partir du moment ou le processeur du PC n'est pas occupé à 100%, peu de chance que ça arrive.
De la même façon, le parasitage electrique de l'USB est rare (bien plus qu'on pourrait le penser) et son influence est souvent marginale et inaudible.

En bref, un simple PC portable avec n'importe quel OS suffit pour faire un "PC Audiophile" (là je sens que je vais m'attirer les foudres des puristes Smile )

Pas seulement des puristes !!!
Peux tu m'expliquer les contrôles CRC sur l'Upnp et la liaison USB avec un DAC? Et plus exactement quelle est la couche informatique dans un DAC, qui pourrait faire un tel contrôle ?
Qu'as tu fait comme expérience ? quels OS?
(03-07-2016, 12:16 AM)Bkg2k a écrit : [ -> ]En bref, un simple PC portable avec n'importe quel OS suffit pour faire un "PC Audiophile" (là je sens que je vais m'attirer les foudres des puristes Smile )

Salut, 
Je pense que tu te trompe.
Je vais te decrire mon parcours afin d'étayer mes propos.

J'ai commencé par un Mac Mini d'origine.
Puis j'ai changé Le cable USB > amélioration par rapport au cable d'imprimante
J'ai opté pour le player Audirvana qui désactive des fonctions non vitales à la lecture > amélioration
Je suis ensuite passé sur une alimentation externe de qualité > grosse amélioration 
J'ai ensuite installé un kit fanless >grosse amélioration 
Puis un REGEN > nette amélioration, preuve que l'usb était encore pollué.
Mon processeur travaillait à environ 6% lors de la lecture de fichiers + une centaine de fils actifs
J'ai installé des scripts d'optimisation audio pour tomber à 3% et 70 fils > amélioration

Je suis passé un peu plus tard à l'installation de l'Os sur une carte SD > grosse amélioration 
Et sur la lecture Qobuz, je me suis ammusé à débrancher le disque interne du SATA > encore une amélioration !

Tout ça pour dire que nos ordinateurs sont hyper pollués.
Un travail sur le hardware s'entendra, meme avec un DAC asynchrone car ce dernier aura moins de travail à fournir.
Un petit laptop USB est une source bien sympa mais n'échappe pas à cette règle.

J'ai un ami de l'ancienne école qui me répète souvent que le son, c'est avant tout de l'électricité.
Plus elle est propre, mieux c'est. 
C'est valable d'un bout à l'autre de la chaîne.

Pascal
(03-07-2016, 12:30 AM)Olivier a écrit : [ -> ]Pas seulement des puristes !!!
Peux tu m'expliquer les contrôles CRC sur l'Upnp et la liaison USB avec un DAC? Et plus exactement quelle est la couche informatique dans un DAC, qui pourrait faire un tel contrôle ?
Qu'as tu fait comme expérience ? quels OS?

Alors, sans etaler mon CV, il est trop long, j'ai plus de 30ans d'experience, en informatique bas niveau. Une solide experience en electronique numerique, et de bonne connaissances en electronique tout court.
J'ai aussi de très solides conaissances dans les protocoles de transmission, protocoles series classiques, protocols reseaux, etc...
Coté OS, j'ai cotoyé tous les OS de ces 30 dernières années, en desktop comme en embarqué.
J'ai commencé l'informatique à 9 ans (vous pouvez en deduire mon age approximatif Wink ) et l'electronique quelques années après.
Actuellement, même si je ne peux pas tout dire, je bosse dans une société ou je travaille sur un module embarqué qui fait de la capture et de la restauration (comprendre réparation) de signaux basse frequences (non audio).

Dans le cas qui nous interesse, pas d'UPNP. Juste un protocole USB 2.0 hardware, couplé a un protocole USB Audio asynchrone (ou isosynchrone comme on trouve aussi).
Le procotole USB 2.0 transmet à une frequence elevée de 480Mb/s, une frequence bien loin des frequences Audio, même raportée en octet/s ou même en sample/s.

Le protocole asynchrone permet un transfert... asynchrone! piloté par le recepteur. A partir de là, plus besoin d'être parfaitement "à la même vitesse" des deux coté. Le buffer et les demandes du recepteur au moment ou il le desire feront fonctionner le transfert parfaitement. De la même façon, les diverses latences informatiques sont pleinement absorbées.
Donc, je repete, n'importe quel PC qui peut transferer en USB 2.0 fait l'affaire.

L'erreur que font beaucoup de personnes, c'est de penser que la transmission est effectuée en temps réel, au fil du l'eau du flux Audio. Il n'en est rien. L'USB est un protocole qui envoi des paquets de données, controlés par CRC, pas un flux de bit audios continu.
Un peu de lecture (le second lien est très interressant Smile)
https://en.wikipedia.org/wiki/USB
http://www.edn.com/design/consumer/43761...-USB-Audio


Pour les féneants, un passage qui resume, du second lien:
Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism.

Lorsqu'on a compris les fondement de la transmission Audio numerique vers un DAC, on comprends que le seul responsable de la qualité de l'écoute finale, c'est le DAC, et personne d'autre. C'est lui qui va gerer la cadence des paquets USB et ses buffers mémoire. A partir du moment ou le PC de l'autre coté n'est pas a genoux, tout se passera bien.

On comprendra aussi qu'un hub USB, actif ou passif, ne change également rien à l'ecoute (au pire, il est chargé comme une mule, l'USB 2.0 sature, et le son va se couper ou ne pas se jouer du tout, j'ai déjà testé). Il en va de même pour le cable USB, à partir du moment ou il est correctement monté et isolé (un cable a 30€ suffit plus que largement, à moins d'habiter dans un transformateur EDF Smile )

Comme je disais plus haut, si le PC ne suit pas (processeur occupé, probleme hardwares, ...) le recepteur (le DAC) va s'affoler, demander au PC d'envoyer la suite, jusqu'au moment ou il n'aura plus de données fraiches. Dans un tel cas, il va soit ne rien faire (trou dans la continuité sonnore), soit rejouer ses anciens buffers, et on aura l'impression d'un leger acoup, ou d'un disque rayé (c'est le cas de la plupart des DAC, j'ai testé sur tous les miens).
Citation :J'ai commencé par un Mac Mini d'origine.
Puis j'ai changé Le cable USB > amélioration par rapport au cable d'imprimante
J'ai opté pour le player Audirvana qui désactive des fonctions non vitales à la lecture > amélioration
Je suis ensuite passé sur une alimentation externe de qualité > grosse amélioration
J'ai ensuite installé un kit fanless >grosse amélioration
Puis un REGEN > nette amélioration, preuve que l'usb était encore pollué.
Mon processeur travaillait à environ 6% lors de la lecture de fichiers + une centaine de fils actifs
J'ai installé des scripts d'optimisation audio pour tomber à 3% et 70 fils > amélioration

Je suis passé un peu plus tard à l'installation de l'Os sur une carte SD > grosse amélioration
Et sur la lecture Qobuz, je me suis ammusé à débrancher le disque interne du SATA > encore une amélioration !

Vu le nombre de grosses améliorations on se dit que le son devait être vraiment pourri de base Big Grin

Je file Big Grin
(03-07-2016, 02:19 AM)Pascal64 a écrit : [ -> ]J'ai un ami de l'ancienne école qui me répète souvent que le son, c'est avant tout de l'électricité.
Plus elle est propre, mieux c'est. 
C'est valable d'un bout à l'autre de la chaîne.

Pascal

Oui, je suis tout a fait d'accord avec toi en ce qui concerne l'analogique. Le transport propre d'un signal analogique dependra de tout un tas de facteurs, dont la qualité et les materieux des cables. Sur la chaine analogique, je suis comme tout le monde, je cherche les meilleurs materiaux et les meilleurs qualités electriques, pour un rendu en bout de chaine des plus fidèle Smile

En numerique, non. En numerique, a partir du moment ou la partie reception peut correctement interpreter les signaux binaire, tout est bon, et plus rien n'influence la qualité d'écoute, hormis le decodeur final et ce qu'il y a derrière.

J'ai fais des blinds tests avec des cables USB il n'y a pas longtemps pour demontrer l'absurdité de la surenchère des cables USB. Croire qu'un cable USB peut influence de signal musical final, c'est croire qu'un cable USB est incapable de transporter proprement de la donnée numerique. Quel carnage l'informatique serait si c'etait le cas! Vous imaginez les copies sur disques sur externe si l'USB etait aussi imprecis sur les d'informations transportées?

Pour faire une analogie criante:
Si je vous dis qu'en changeant le cable HDMI entre mon lecteur bluray et ma TV, j'ai de meilleures couleurs et un contraste plus profond, vous allez me rire au nez! Et vous aurez raison... (si vous ne le faire pas, là je vais serieusement m'inquieter!)
Comme en Audio, la seule responsable de la qualité d'image finale, c'est la TV. En aucun cas le lecteur bluray, et encore moins le cable HDMI.
Si le cable est defectueux, ou trop juste pour les frequences qu'on lui demande, vous obtiendrez une image noire, ou au pire, quelques artefacts sur l'images (les "carrés jpeg"). Mais un cable HDMI, qui transporte des données numeriques, n'a strictement aucune influence sur la balance des couleurs, la luminosité ou la profondeur des noirs.

Idem pour un cable USB. Et c'est d'autant plus facile pour l'USB, qui ne transporte que du Mb/s, là ou pour la videos, on est dans les Gb/s, des frequences plus difficiles à gerer electiquement parlant.
(03-07-2016, 10:30 AM)Bkg2k a écrit : [ -> ]Le protocole asynchrone permet un transfert... asynchrone! piloté par le recepteur. A partir de là, plus besoin d'être parfaitement "à la même vitesse" des deux coté. Le buffer et les demandes du recepteur au moment ou il le desire feront fonctionner le transfert parfaitement. De la même façon, les diverses latences informatiques sont pleinement absorbées.
Donc, je repete, n'importe quel PC qui peut transferer en USB 2.0 fait l'affaire.


L'erreur que font beaucoup de personnes, c'est de penser que la transmission est effectuée en temps réel, au fil du l'eau du flux Audio. Il n'en est rien. L'USB est un protocole qui envoi des paquets de données, controlés par CRC, pas un flux de bit audios continu.
Un peu de lecture (le second lien est très interressant Smile)
https://en.wikipedia.org/wiki/USB
http://www.edn.com/design/consumer/43761...-USB-Audio


Pour les féneants, un passage qui resume, du second lien:
Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism.

Lorsqu'on a compris les fondement de la transmission Audio numerique vers un DAC, on comprends que le seul responsable de la qualité de l'écoute finale, c'est le DAC, et personne d'autre. C'est lui qui va gerer la cadence des paquets USB et ses buffers mémoire. A partir du moment ou le PC de l'autre coté n'est pas a genoux, tout se passera bien.

On comprendra aussi qu'un hub USB, actif ou passif, ne change également rien à l'ecoute (au pire, il est chargé comme une mule, l'USB 2.0 sature, et le son va se couper ou ne pas se jouer du tout, j'ai déjà testé). Il en va de même pour le cable USB, à partir du moment ou il est correctement monté et isolé (un cable a 30€ suffit plus que largement, à moins d'habiter dans un transformateur EDF Smile )

Comme je disais plus haut, si le PC ne suit pas (processeur occupé, probleme hardwares, ...) le recepteur (le DAC) va s'affoler, demander au PC d'envoyer la suite, jusqu'au moment ou il n'aura plus de données fraiches. Dans un tel cas, il va soit ne rien faire (trou dans la continuité sonnore), soit rejouer ses anciens buffers, et on aura l'impression d'un leger acoup, ou d'un disque rayé (c'est le cas de la plupart des DAC, j'ai testé sur tous les miens).



Oui ! Mais dans un DAC, qu'est-ce qui fait ce contrôle ?
La problématique n'est pas sur le débit, un débit USB2.0 suffit amplement à faire passer ce nous intéresse, qu'il y ait controle ou non (tout comme en Upnp d'ailleurs).

Sur la partie logiciel: as tu testé TinySqueeze ? Comment expliques tu les différences audibles (sans concentration excessive) quand on joue juste avec les priorités des process? Ou juste en comparaison avec un Windows?

Aussi, comment expliques tu les différences, toujours, audibles lorsqu'on travaille la partie alimentation d'un PC : alimentation linéaire ou batterie?
(03-07-2016, 11:10 AM)Bkg2k a écrit : [ -> ]J'ai fais des blinds tests avec des cables USB il n'y a pas longtemps pour demontrer l'absurdité de la surenchère des cables USB. Croire qu'un cable USB peut influence de signal musical final, c'est croire qu'un cable USB est incapable de transporter proprement de la donnée numerique. Quel carnage l'informatique serait si c'etait le cas! Vous imaginez les copies sur disques sur externe si l'USB etait aussi imprecis sur les d'informations transportées?

Pour faire une analogie criante:
Si je vous dis qu'en changeant le cable HDMI entre mon lecteur bluray et ma TV, j'ai de meilleures couleurs et un contraste plus profond, vous allez me rire au nez! Et vous aurez raison... (si vous ne le faire pas, là je vais serieusement m'inquieter!)
Comme en Audio, la seule responsable de la qualité d'image finale, c'est la TV. En aucun cas le lecteur bluray, et encore moins le cable HDMI.
Si le cable est defectueux, ou trop juste pour les frequences qu'on lui demande, vous obtiendrez une image noire, ou au pire, quelques artefacts sur l'images (les "carrés jpeg"). Mais un cable HDMI, qui transporte des données numeriques, n'a strictement aucune influence sur la balance des couleurs, la luminosité ou la profondeur des noirs.

Idem pour un cable USB. Et c'est d'autant plus facile pour l'USB, qui ne transporte que du Mb/s, là ou pour la videos, on est dans les Gb/s, des frequences plus difficiles à gerer electiquement parlant.

Encore une fois: ce n'est pas un problème de transport ! Personne (enfin je crois) a affirmé qu'il faudrait avoir un cable USB THDG pour transporter l'absolue intégralité du signal ! J'atteste, et sans risque qu'un cable d'imprimante le fait très bien aussi !
Pour ton analogie sur l'HDMI, je suis d'accord, n'ayant absolument rien remarqué entre un cable HDG et un cable HDMI no name. Par contre, pour une petite digression, en terme d'image: entre une source quelconque (lecteur bas de gamme ou PC) et un lecteur bluray (ou PCHC amélioré) un peu plus travaillé, je ne peux pas te laisser dire, qu'il n'y a pas de différence visible (sans se coller le nez à l'écran)! et sur le même écran !
Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33