De l'utilité de l'upsampling...

[staki]

oui bien sur mais les méthodes divergent sur la façon de procédé aux mesure. De plus il n' y a pas q'une sorte de jitter a proprement parlé. mais dans le cas qui nous intéresse la méthode de l' AES exploité par Stereophile me semble logique. Il faut un analyseur de spectre.

http://www.msbtech.com/support/JitterPaper.pdf

Le meilleur appareil pour analyser le Jitter est un appareil de la marque Audio Precision, fabriqué spécialement pour ça, mais il coûte 20'000 dollars.....

[robob]

cela ne marche que dans les convertiseurs hardware externes. Il est bien évident que cela ne sert à rien d'upsampler sur un pc, cela ne fera qu'augmenter le bruit de l'alimentation, du CPU et de la carte-mère en général, au détriment de la qualité. Ceux qui croient percevoir une plus grande qualité se font en réalité berner par les artefacts de l'upsampling software, qui a tendance à lisser le son, à le rendre plus "doux", mais en fait c'est une illusion, il y a une réelle perte d'informations.

1-Pourquoi est-ce bien évident ?
2-Le bruit, quel bruit ? il s'agit d'un transfert de données numériques par SPIF vers un DAC.

[staki]

cela ne marche que dans les convertiseurs hardware externes. Il est bien évident que cela ne sert à rien d'upsampler sur un pc, cela ne fera qu'augmenter le bruit de l'alimentation, du CPU et de la carte-mère en général, au détriment de la qualité. Ceux qui croient percevoir une plus grande qualité se font en réalité berner par les artefacts de l'upsampling software, qui a tendance à lisser le son, à le rendre plus "doux", mais en fait c'est une illusion, il y a une réelle perte d'informations.

1-Pourquoi est-ce bien évident ?
2-Le bruit, quel bruit ? il s'agit d'un transfert de données numériques par SPIF vers un DAC.

1) sur les cartes son, il n'y a pas de puce ASRC. Les données arrivent sous forme de paquets, puis sont cadencées une seule fois par l'horloge de la carte son, soit vers la sortie spdif sous forme de flux pcm, soit vers la puce de conversion incorporée à la carte son. Donc augmenter l'échantillonnage ne changera rien au jitter. Le jitter dépend avant tout de la précision de l'horloge de la carte son (et dans une moindre mesure de la pureté des alims, et de la qualité générale du tracé des pistes et plans de masse).

2) si l'on tient malgré tout à effectuer un upsampling, cela fera travailler fortement le microprocesseur, la mémoire vive et l'ensemble des circuits de la carte-mère, donc cela augmentera le bruit d'alimentation (parasites hautes fréquences). D'avoir une alimentation plus bruitée (= plus polluée) ne fera qu'augmenter le jitter de l'horloge, donc au final on aura un son de moindre qualité.

Des tests très intéressants ont été effectués sur une carte son professionnelle RME *. En lisant les fichiers au format natif (sans aucune conversion = bitperfect), on arrive à un jitter de 50 pico-secondes, ce qui est quatre fois meilleur que les meilleurs drives séparés super haut de gamme qui ont au minimum 200 pico-secondes de jitter en sortie spdif. (il faut que je fasse des recherches, je n'ai pas l'adresse du site en tête......)
Par contre en upsamplant (donc je rappelle en multipliant par une fraction, donc en faisant faire de très lourds calculs au processeur), on augmente le taux de jitter à cause de la pollution des lignes d'alimentation.
D'où une dégradation du son......

On n'insistera jamais assez sur le problème du jitter dans l'audio numérique. Les professionnels en ont pris conscience à la fin des années quatre-vingts.
Dans un convertisseur "hifi", on estime que la qualité se répartit comme cela : 30 % pour la puce de conversion elle-même, 30% pour l'étage de sortie analogique, et le reste, donc 40 %, pour la précision de l'horloge, la pureté des alimentations, et la qualité générale des pistes, plans de masse, etc, du circuit imprimé.

* RME 96-8 PST, carte obsolète qui n'est plus fabriquée. Avec les nouvelles cartes PCI ou PCIe (9632, AIO, etc) le jitter est encore plus faible !

[AlexScan]

Question donc , le firewire transmet les infos comme une liaison réseau , donc aucun jitter ?

[robob]

* RME 96-8 PST, carte obsolète qui n'est plus fabriquée. Avec les nouvelles cartes PCI ou PCIe (9632, AIO, etc) le jitter est encore plus faible !

Donc déjà avec cette RME "préhistorique" , le jitter était négligeable. Je ne serais pas étonné qu'une sortie SPDIF de carte mere actuelle munie d'un vulgaire chipset dit "HD" donne de meilleur résultat : le chipset étant integré à la carte mere reduisant encore le "chemin" de parcours ainsi que les connexions (carte son sur slot PCI ou externe, reste à voir le protocole de transfert des données): donc moins de gigue. Quand aux horloges CPU, je pense qu'elles sont aujourd'hui largement calibrées et précises pour tenir un petit 192 khz. Idem pour la puissance de calcul permettant d'upsampler un flux audio : A titre indicatif, sans upsampling en lecture sous foobar je suis autour de 18% d'occupation CPU (Foobar avec skin un peu chargé : vu-metre et autres gadgets ). Avec l'upsampling (resampler SoX) je passe à ...20% en moyenne (processeur AMD athlon II X3 425).

augmenter l'échantillonnage ne changera rien au jitter. Le jitter dépend avant tout de la précision de l'horloge de la carte son...si l'on tient malgré tout à effectuer un upsampling...cela ne fera qu'augmenter le jitter de l'horloge

C'est bien possible, mais en passant de 44.1 à 192 khz, on découpe et on envoie 4.35 fois plus d'information au DAC : c'est lui qui doit corriger les problemes eventuels de jitter avec une bonne horloge et un buffer d'entrée. D'apres moi, cela devrait lui donner 4.35 fois plus souvent la possibilité d'être plus proche du signal d'origine.

Et la boite qui nous sort une puce de converstion N/A equipée d'un buffer et d'un recepteur de donnée en vulgaire TCP, on entendra définitivement plus parler de jitter comme cause de perte de qualité audio.

[robob]

Question donc , le firewire transmet les infos comme une liaison réseau , donc aucun jitter ?

Non, les données audio et vidéo sont acheminées en mode isochrones donc sans renvoie d'erreur, seules les données info circulent en asynchrone. (Peut-être que certaines cartes son utilisent ce mode).

[staki]

Question donc , le firewire transmet les infos comme une liaison réseau , donc aucun jitter ?

Je ne suis pas un spécialiste du Firewire, mais je crois savoir qu'il n'a pas le même protocole de transmission de données que le réseau tcp/ip. Il me semble que le firewire fonctionne comme de l'USB isochrone, des paquets de données sont transmis tous les x millisecondes, mais cadencés par l'horloge du bus lui-même, donc sensibles au jitter.

Je sais que RME, pour certaines de ses cartes son externes, a développé son propre protocole de transmission, qui, bien qu'utilisant les mêmes prises et câbles que le firewire, fonctionne différemment, car ils n'étaient pas satisfaits de la qualité de transmission du firewire classique.
Il faudrait voir sur leur site s'il y des infos plus poussées......sans certitude car ils sont assez jaloux de leurs techniques propriétaires (ce qui se comprend, la concurrence, les brevets, tout ça.... )

[staki]

Donc déjà avec cette RME "préhistorique" , le jitter était négligeable. Je ne serais pas étonné qu'une sortie SPDIF de carte mere actuelle munie d'un vulgaire chipset dit "HD" donne de meilleur résultat : le chipset étant integré à la carte mere reduisant encore le "chemin" de parcours ainsi que les connexions (carte son sur slot PCI ou externe, reste à voir le protocole de transfert des données): donc moins de gigue.

Tout dépend par rapport à quelle carte son on fait la comparaison. Par rapport à des cartes "grand public" ce ne serait pas étonnant en effet qu'il y ait moins de jitter sur une sortie spdif intégrée, ou en tout cas pas plus.
Mais par rapport à une carte son pro je ne pense pas. Il ne faut pas oublier que les horloges de cartes-mère ne sont absolument pas faites pour de l'audio. Pour le fonctionnement en "traitement de données informatiques" de l'ordinateur, le jitter n'a pas du tout la même importance que pour du flux audio en temps réel.
Et les chipset son intégrés font travailler toute la carte-mère, avec les problèmes de pollution des alimentations évoqués avant.
Par contre les cartes son RME par exemple gèrent elles-même le port PCI et l'accès aux données sur le disque dur, donc elles polluent moins les lignes d'alimentation. En langage "marketing" ils appellent ça la "technologie 0 CPU" !!
Et elles sont équipées d'horloges à très faible jitter contrairement aux cartes-mères......

En plus il faut voir si le chipset intégré est capable de faire du kernel streaming. S'il passe par le mixer, il rééchantillonne, et on se retrouve avec le problème de bruit généré par l'activité du CPU........

Quand aux horloges CPU, je pense qu'elles sont aujourd'hui largement calibrées et précises pour tenir un petit 192 khz. Idem pour la puissance de calcul permettant d'upsampler un flux audio : A titre indicatif, sans upsampling en lecture sous foobar je suis autour de 18% d'occupation CPU (Foobar avec skin un peu chargé : vu-metre et autres gadgets ). Avec l'upsampling (resampler SoX) je passe à ...20% en moyenne (processeur AMD athlon II X3 425).

Avec une carte RME 9632, je suis à 0 % d'utilisation CPU (sans resampling bien sûr ), et ça sur une carte-mère mini-itx avec un tout petit proco VIA C7 à 1 GHz !

C'est bien possible, mais en passant de 44.1 à 192 khz, on découpe et on envoie 4.35 fois plus d'information au DAC : c'est lui qui doit corriger les problemes eventuels de jitter avec une bonne horloge et un buffer d'entrée. D'apres moi, cela devrait lui donner 4.35 fois plus souvent la possibilité d'être plus proche du signal d'origine.

Là je ne sais pas trop quoi répondre. En principe non, car si on suit le théorème de Shannon, avec une fréquence d'échantillonnage de 44.1 KHz on devrait être capable de reconstruire le signal sans aucune perte, donc pas besoin d'avoir une fréquence d'échantillonnage plus élevée. Mais là je préfèrerais laisser parler des personnes plus compétentes que moi.......

Et la boite qui nous sort une puce de converstion N/A equipée d'un buffer et d'un recepteur de donnée en vulgaire TCP, on entendra définitivement plus parler de jitter comme cause de perte de qualité audio.

Entièrement d'accord, le jour où un tel convertisseur externe existe, plus aucun problème. C'est même étonnant que ça n'existe pas encore.......

[robob]

Enfin merci pour la definition comparative upsampling <-> oversampling : maintenant je sais quelle est la différence...
Pour l'occupation CPU, je soulignais juste la différence entre avec et sans upsampling : c'est vrai que 18% du CPU pour juste faire tourner un player musique sur un triple core, c'est pas leger leger ! Je pense que je vais sucrer le skin foobar et revenir à une version allégée. Apres tout pour ecouter de la musique, pas besoin d'image. Et d'accord sur le fait qu'il vaut mieux avoir un PC qui tourne au minimum : même en utilisant des drivers asio ou Wasapi, on ne sait jamais tout à fait comment Windows partage les temps de travail et quelles peuvent être les implications sur la lecture audio.

[staki]

Moi aussi il m'a fallu digérer pas mal de pages de forums anglophones pour enfin comprendre la différence entre up et oversampling ! Ce n'était jamais clairement expliqué !!

C'est vrai que c'est bizarre un taux d'occupation CPU aussi élevé !! Tu es sûr que ça vient du skin ? C'est peut-être aussi les pilotes de ta carte son ?

Juste pour voir j'ai fait des essais d'upsampling en temps réel avec Foobar et un plugin, ben il y a tout qui se fige chez moi ! Le proco VIA C7 n'est clairement pas assez puissant pour ça !
Si un jour je voulais faire du Digital Room Correction ou un filtrage actif, il me faudrait au minimum une carte mini-itx avec un Intel Atom 2 x 1.6 GHz..........

Ou alors installer une distro Linux légère, et utiliser MPD comme serveur audio, avec un client en lecture.

[AlexScan]

Si un jour je voulais faire du Digital Room Correction ou un filtrage actif, il me faudrait au minimum une carte mini-itx avec un Intel Atom 2 x 1.6 GHz.........

Je le fait avec un égaliseur paramétrique (electri-Q) et ça bouffe que dalle en CPU .

Par contre j'ai fait des essai avec foobar Xover pour le filtrage actif , et la mon petit Sempron LE 1200 était à genoux !

[staki]

Oui, il me semble que pas mal de plugins Foobar consomment énormément de ressources !
Défaut de conception du programme ? Je me le demande.........

[AlexScan]

C'est possible mais Electri Q n'est pas un plugin Foobar , mais un plugin VST , il faut le plugin "Foobar George Yohng's VST wrapper" pour le faire fonctionner !

[staki]

Oui, on s'est bien compris.

ElectriQ qui n'est pas un plugin Foobar ne fait presque rien consommer en CPU, alors que Xover qui lui est un plugin Foobar met ton Sempron à genoux !
Et chez moi le Secret Rabbit Code qui est aussi un plugin Foobar met mon C7 à genoux également.

D'où ma réflexion sur les plugins Foobar.......

[AlexScan]

Et chez moi le Secret Rabbit Code qui est aussi un plugin Foobar met mon C7 à genoux également.

Chez moi aussi , alors que le SoX non , pourtant il fait un meilleur boulot !